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Abstract 


This  report  covers  a  number  of  Human  Factors  (HF)  issues  relating  to  the  role  of  the  operator 
and  the  operator  machine  interface  (OMI)  in  sonar  processing.  The  first  section  of  the  report 
updates  an  existing  function  analysis  of  the  CANadian  Towed  Array  Sonar  System  (CANTASS) 
to  incorporate  ongoing  operational  functions  that  have  emerged  since  the  original  analysis  was 
conducted.  The  second  section  of  the  report  reviews  relevant  literature  that  addresses  design 
issues  for  the  OMI  of  sonar  combat  systems.  No  specific  guidelines  were  found  that  could  be 
directly  applied  to  the  design  of  new  sonar  systems.  However,  some  useful  generic  principles  for 
the  display  of  tactical  information,  for  representing  the  underwater  environment,  for  data 
visualisation  and  for  supporting  military  command  decision-making  were  obtained. 

The  third  section  of  the  report  outlines  a  function  analysis  of  the  Towed  Integrated  Active  Passive 
Sonar  (TIAPS)  system  based  upon  its  present  state  of  development,  reviews  HF  considerations  of 
the  TIAPS  OMI  and  examines  core  functions.  These  include  configuring  the  system,  monitoring, 
evaluating  and  refining  automated  processes,  analysing  the  "truth"  concerning  auto-detected 
contacts,  building  and  monitoring  the  tactical  picture  and  building  and  maintaining  the  Under  Water 
(UW)  recognised  maritime  picture  (RMP).  Specific  OMI  design  issues  are  identified  in  areas  with 
respect  to  display  design,  tools  to  support  contact  analysis,  workstation  configuration,  software 
navigation  and  communication  of  spatial  information.  The  analysis  also  examined  broader  and 
more  fundamental  problems  concerning  the  relationship  between  the  operator  and  automated  system 
functions,  notably  trust  in  automation  and  the  need  to  for  operators  to  comprehend  limitations  in  the 
data  produced  by  automated  detectors  and  trackers.  Finding  solutions  to  the  human-system 
problems  associated  with  more  automation  is  identified  as  an  equally  important  research  concern  as 
developing  the  robust  algorithms  that  make  automation  feasible. 

The  final  section  deals  with  future  research  and  development  activities  that  may  be  required  to 
support  ongoing  TIAPS  evolution  from  technology  demonstrator  to  operational  service. 
Recommended  areas  for  research  include  operator  interaction  with  automated  systems,  allocation 
of  function  among  the  system  and  team  members,  improving  the  capability  of  the  operator  to 
visualise  the  tactical  UW  environment  and  function  and  design  issues  concerning  the  role  of  the 
tactical  display. 
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Resume  analytique 

Le  present  rapport  traite  d'un  certain  nombre  de  facteurs  humains  (FH)  relatifs  au  role  de 
l'operateur  et  de  1' interface  operateur-machine  (IOM)  en  traitement  sonar.  La  premiere  partie  de 
ce  rapport  presente  une  mise  h  jour  d'une  analyse  de  fonction  pr6cedente  portant  sur  le  Systeme 
sonar  a  reseau  remorque  canadien  (CANTASS)  visant  a  integrer  des  fonctions  operationnelles  qui 
ont  vu  le  jour  depuis  la  periode  ou  1' analyse  prec6dente  avait  ete  effectuee.  La  deuxieme  partie 
de  ce  rapport  passe  en  revue  la  litterature  pertinente  qui  traite  des  questions  de  conception  des 
IOM  des  systemes  sonar  de  combat.  Aucune  ligne  directrice  pouvant  s'appliquer  directement  a 
la  conception  de  nouveaux  systemes  sonar  n'a  ete  relevee.  Par  ailleurs,  quelques  principes 
generaux  utiles  en  matiere  d'affichage  de  renseignements  tactiques,  de  representation  de 
l'environnement  sous-marin,  de  visualisation  des  donnees  et  de  soutien  a  la  prise  de  decision  dans 
le  domaine  du  commandement  militaire  ont  ete  formules. 

La  troisieme  partie  du  rapport  decrit  une  analyse  des  fonctions  du  Sonar  remorque  integre  actif 
passif  (TIAPS)  fondee  sur  son  degre  de  developpement  actuel  et  elle  examine  des  facteurs 
humains  en  jeu  dans  1'IOM  du  TIAPS  et  ses  fonctions  essentielles.  Ces  fonctions  comprennent  la 
configuration  et  la  surveillance  du  systeme,  revaluation  et  le  perfectionnement  des  processus 
automatises,  1' analyse  de  la  «  veracite  »  des  contacts  detectes  automatiquement,  1' elaboration  et  le 
maintien  du  tableau  tactique  et  le  maintien  du  Tableau  de  la  situation  maritime  (TSM)  sous- 
marine.  Des  questions  de  conception  specifiques  a  1'IOM  sont  soulignees  dans  des  domaines 
comme  la  conception  de  1'affichage,  les  outils  pour  1' analyse  des  contacts,  la  configuration  des 
postes  de  travail,  la  navigation  dans  le  logiciel  et  la  communication  d' information  spatiale.  Cette 
analyse  a  aussi  porte  sur  le  probleme,  plus  vaste  et  plus  fondamental,  de  la  relation  entre 
l'operateur  et  les  fonctions  automatisees  du  systeme,  en  particulier  la  confiance  accordee  par 
l'operateur  aux  fonctions  automatisees  et  le  besoin  qu'a  l'operateur  de  comprendre  les  limites  des 
donnees  produites  par  les  detecteurs  et  les  dispositifs  de  poursuite  automatises.  La  decouverte  de 
solutions  aux  problemes  associes  a  l'accroissement  de  1'automatisation  sur  le  plan  de  la  relation 
entre  les  persones  et  les  systemes  est  relevee  comme  etant  un  sujet  de  recherche  aussi  important 
que  1'elaboration  des  algorithmes  robustes  qui  rendent  possible  1'automatisation. 

La  section  finale  traite  des  activites  de  recherche  et  developpement  futures  qui  pourraient  etre 
requises  afin  d'aider  a  1'evolution  du  TIAPS  du  statut  de  demonstrates  de  technologie  au  statut 
de  service  operationnel.  Les  domaines  de  recherche  recommandes  comprennent  1' interaction 
entre  l'operateur  et  les  systemes  automatises,  1' allocation  des  fonctions  entre  le  systeme  et  les 
membres  de  l'equipe,  l'amelioration  de  la  capacite  de  l’operateur  a  visualiser  l’environnement 
tactique  sous-marin,  ainsi  que  les  questions  de  fonction  et  de  conception  en  ce  qui  concerne  le 
role  de  1'affichage  tactique. 
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Executive  Summary 


This  report  is  in  four  parts  and  covers  a  number  of  Human  Factors  (HF)  issues  relating  to  the 
role  of  the  operator  and  the  operator  machine  interface  (OMI)  in  sonar  processing.  The  first  part 
of  the  report  updates  an  existing  function  analysis  of  the  CANadian  Towed  Array  Sonar  System 
(CANT ASS)  to  incorporate  ongoing  operational  functions  that  were  not  uncovered  as  part  of  the 
original  analysis.  These  functions  are  added  onto  the  basic  structure  of  the  original  analysis  that 
remains  substantially  unchanged. 

The  second  part  of  the  report  reviews  relevant  literature  that  addresses  design  issues  for  the  OMI 
of  sonar  combat  systems.  The  literature  was  divided  into  categories  that  addressed  sonar 
systems,  military  combat  systems,  military  and  non-military,  general,  design  guidelines  and  data 
visualisation.  No  specific  guidelines  were  found  that  could  be  directly  applied  to  the  design  of 
new  sonar  systems.  However,  some  useful  generic  principles  for  the  display  of  tactical 
information,  for  representing  the  underwater  environment,  for  data  visualisation  and  for 
supporting  military  command  decision  making  were  obtained. 

The  third  part  of  the  report  outlines  a  function  analysis  of  the  Towed  Integrated  Active  Passive 
Sonar  (TIAPS)  system  based  upon  its  present  state  of  development.  The  operational  goal  of 
TIAPS  is  defined  as  building  and  maintaining  the  underwater  tactical  picture.  The  specific 
functions  that  support  this  are  decomposed  down  to  sufficient  levels  to  understand  the  major  tasks 
involved  and  associated  function  descriptions  and  flow  diagrams  are  provided  in  an  Annex.  The 
second  section  of  this  part  provides  a  HF  review  of  the  TIAPS  OMI  and  examines  core  functions. 
These  functions  involve:  configuring  the  system,  monitoring,  evaluating  and  refining  automated 
processes,  analysing  the  "truth"  concerning  auto-detected  contacts,  building  and  monitoring  the 
tactical  picture  and  building  and  maintaining  the  Under  Water  (UW)  recognised  maritime  picture 
(RMP).  Specific  OMI  design  issues  are  identified  in  areas  with  respect  to  display  design,  tools  to 
support  contact  analysis,  workstation  configuration,  software  navigation  and  communication  of 
spatial  information.  The  analysis  also  examined  the  broader  problem  concerning  the  relationship 
between  the  operator  and  automated  system  functions.  Issues  such  as  operator  trust  in  automated 
functions,  the  implications  of  automation  on  the  role  of  the  operator  and  assignment  of  functions 
to  human  or  system  are  discussed. 

The  final  section  deals  with  future  research  and  development  activities  that  may  be  required  to 
support  ongoing  TIAPS  evolution  from  technology  demonstrator  to  operational  service. 
Recommended  areas  for  research  include  operator  interaction  with  automated  systems,  allocation 
of  function  among  the  system  and  team  members,  displaying  the  tactical  UW  environment, 
function  and  design  issues  concerning  the  role  of  the  tactical  display. 

It  is  concluded  that  the  function  analysis  of  TIAPS  is  timely  and  not  only  provides  a  foundation 
for  understanding  the  system  from  an  operational  perspective,  but  also  serves  as  a  framework  for 
future  analyses.  It  is  recommended  that  further  HF  analyses  be  integrated  with  the  build  and  test 
development  process  to  ensure  that  OMI  and  operator  function  issues  receive  their  own  focus  of 
development  beyond  the  current  emphasis  on  ensuring  that  the  underlying  technological  concepts 
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are  sound  and  can  be  implemented.  Future  analyses  will  also  be  required  to  evaluate  the 
emerging  tool  suite  in  terms  of  its  utility  and  usability  to  ensure  that  it  will  support  the  core 
functions  of  detection,  analysis,  classification  and  tactical  decision  making.  Task  network 
simulation  is  recommended  as  a  method  for  evaluating  design  options  as  well  as  investigating  the 
complex  balance  between  operator  tasks  and  automated  system  functions. 
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Resume 


Le  present  rapport  en  quatre  parties  traite  d'un  certain  nombre  de  facteurs  humains  (FH)  relatifs 
au  role  de  l'operateur  et  de  1' interface  operateur-machine  (IOM)  en  traitement  sonar.  La 
premiere  partie  de  ce  rapport  pr6sente  une  mise  a  jour  d'une  analyse  de  fonction  precedente 
portant  sur  le  Systeme  sonar  k  reseau  remorque  canadien  (CANT ASS)  visant  a  integrer  des 
fonctions  operationnelles  qui  ont  vu  le  jour  depuis  la  periode  ou  1' analyse  precedente  avait  ete 
effectu6e.  Ces  fonctions  sont  ajout6es  a  la  structure  de  base  de  l'analyse  originate,  qui  demeure 
essentiellement  inchangee. 

La  deuxieme  partie  de  ce  rapport  passe  en  revue  la  litterature  pertinente  qui  traite  des  questions 
de  conception  des  IOM  des  systemes  sonar  de  combat.  Cette  documentation  a  ete  divisee  en 
categories  correspondant  aux  systemes  sonar  militaires  et  non  militaires,  aux  aspects  generaux, 
aux  principes  de  conception  et  a  la  visualisation  des  donnees.  Aucune  ligne  directrice  pouvant 
s'appliquer  directement  a  la  conception  de  nouveaux  systemes  sonar  n'a  ete  relevee.  Par  ailleurs, 
quelques  principes  generaux  utiles  en  matiere  d'affichage  de  renseignements  tactiques,  de 
representation  de  l'environnement  sous-marin,  de  visualisation  des  donnees  et  de  soutien  a  la 
prise  de  decision  dans  le  domaine  du  commandement  militaire  ont  ete  formules. 

La  troisieme  partie  du  rapport  decrit  une  analyse  des  fonctions  du  Sonar  remorque  integre  actif 
passif  (TIAPS)  fondee  sur  son  degre  de  developpement  actuel.  L'objectif  operationnel  du  TIAPS 
est  defini  comme  etant  1’ elaboration  et  le  maintien  du  tableau  tactique  sous-marin.  Les  fonctions 
specifiques  qui  prennent  en  charge  cet  objectif  sont  decomposees  en  un  nombre  de  niveaux 
suffisant  pour  comprendre  les  principales  taches  requises  et  une  annexe  comporte  les  descriptions 
des  fonctions  ainsi  que  les  ordinogrammes  connexes.  La  deuxieme  section  de  cette  partie 
comporte  un  examen  des  facteurs  humains  en  jeu  dans  1'IOM  du  TIAPS  et  de  ses  fonctions 
essentielles.  Ces  fonctions  comprennent  la  configuration  et  la  surveillance  du  systeme, 
revaluation  et  le  perfectionnement  des  processus  automatises,  l'analyse  de  la  «  veracite  »  des 
contacts  detectes  automatiquement,  l'elaboration  et  le  maintien  du  tableau  tactique  et  le  maintien 
du  Tableau  de  la  situation  maritime  (TSM)  sous-marine.  Des  questions  de  conception  specifiques 
a  1'IOM  sont  soulignees  dans  des  domaines  comme  la  conception  de  l'affichage,  les  outils  pour 
l'analyse  des  contacts,  la  configuration  des  postes  de  travail,  la  navigation  dans  le  logiciel  et  la 
communication  d' information  spatiale  Cette  analyse  a  aussi  porte  sur  le  probleme,  plus  vaste, 
de  la  relation  entre  l'operateur  et  les  fonctions  automatisees  du  systeme.  II  est  aussi  question 
d'autres  sujets  comme  la  confiance  accordee  par  l'operateur  aux  fonctions  automatisees,  les 
consequences  de  l’automatisation  sur  le  role  de  l'operateur  et  l'affectation  de  fonctions  aux 
personnes  ou  aux  systemes. 

La  section  finale  traite  des  activites  de  recherche  et  developpement  futures  qui  pourraient  etre 
requises  afin  d' aider  a  1' evolution  du  TIAPS  du  statut  de  demonstrateur  de  technologie  au  statut 
de  service  operationnel.  Les  domaines  de  recherche  recommandes  comprennent  1' interaction 
entre  l'operateur  et  les  systemes  automatisms,  1' allocation  des  fonctions  entre  le  systeme  et  les 
membres  de  l'equipe,  l'affichage  de  l'environnement  tactique  sous-marin,  ainsi  que  les  questions 
de  fonction  et  de  conception  en  ce  qui  concerne  l'affichage  tactique. 
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On  conclue  en  affirmant  que  1’ analyse  de  fonction  du  TIAPS  est  adequate  et  qu'elle  ne  constitue 
pas  seulement  un  fondement  pour  la  comprehension  du  systeme  d’une  perspective  operationnelle, 
mais  qu'elle  sert  aussi  de  cadre  de  travail  pour  des  analyses  a  venir.  II  est  recommande  que  les 
analyses  futures  des  facteurs  humains  soient  integrees  au  processus  de  developpement  des 
versions  de  developpement  et  des  essais  pour  que  l'on  accorde  plus  d' importance  au 
developpement  de  1'IOM  et  des  fonctions  de  l'operateur,  au-dela  de  celle  qui  leur  est  accordee 
lorsqu'on  s' assure  que  les  principes  technolog  iques  sous-jacents  sont  valables  et  peuvent  etre  mis 
en  oeuvre.  D'autres  analyses  seront  par  ailleurs  requises  afin  d'evaluer  1' ensemble  d'outils  a 
venir  sur  les  plans  de  son  utilite  et  de  son  utilisabilite  afin  de  s' assurer  qu'il  soutiendra  les 
fonctions  essentielles  de  detection,  d’analyse,  de  classification  et  de  prise  de  decision  tactique. 

La  simulation  de  reseaux  de  taches  est  recommandee  comme  methode  devaluation  d'options  de 
conception  ainsi  que  1' etude  de  l'equilibre  complexe  entre  les  tfiches  de  l'operateur  et  les 
fonctions  automatisees  du  systeme. 
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1.  Introduction 


1.1  Background 

This  report  is  the  result  of  work  carried  out  under  PWGSC  Contract  No.  W7711-7-7404/01-SV 

Call  Up:  7404-12  under  the  Scientific  Authority  of  Sharon  McFadden  at  DCIEM.  The  report 
addresses  the  following  requirements  in  the  Statement  of  Work  (SOW): 

Item  #3:  "Review  existing  CANT  ASS  task  analysis "  ( update  function  analysis  to 
include  current  operational  concept  of  CANTASS)1 

ItemM:  "Develop  preliminary  function  analysis  based  on  the  YARD  analysis  and 
update  it  to  include  new  functionality  provided  by  TIAPS  and  SIMS". 

This  initial  tasking  has  been  subsequently  narrowed  in  discussion  with  the  Scientific  Authority  to 
include  only  the  Towed  Integrated  Active  Passive  Sonar  (TIAPS)  system  at  this  point  in  time, 
since  the  evolution  of  the  Sonar  Integrated  Management  System  (SIMS)  program  is  ongoing  and 
not  at  the  point  where  a  meaningfully  representative  function  analysis  can  be  performed.  Further, 
given  that  a  significant  part  of  the  functionality  of  the  proposed  functionality  of  SIMS  has  been 
incorporated  into  TIAPS,  the  report  is  also  relevant  to  the  development  of  SIMS. 

Item  #6:  "Review  available  documentation  and  background  literature  relevant  to 
the  design  of  OMI'sfor  sonar/combat  systems  and  prepare  a  short  summary 
report  on  literature  reviewed. " 

ItemM:  " Prepare  a  report  covering  a  usability  review  of  TIAPS,  usability  of 
current  designs,  limitations  of  the  system,  suggestions  for  improvements  and 
potential  topics  for  long  term  research 2 

1.2  Report  Organisation 

The  report  is  organised  into  the  following  sections,  which  in  many  cases  can  be  read 
independently  of  other  sections: 

Summary  literature  Review  of  Operator  Machine  Interface  (OMI)  issues  for  sonar 
systems 

Extension  of  YARD  CANadian  Towed  Ararray  Sonar  System  (CANTASS)  function 
analysis  to  include  current  operations 

Function  analysis  of  TIAPS 


'  The  latter  tasking  was  appended  in  discussions  with  the  Scientific  Authority 

2  Again,  in  consultation  with  the  Scientific  Authority,  it  was  agreed  that  given  the  current  state  of  TIAPS  system 
development  a  usability  analysis  would  be  premature.  Hence,  as  an  interim  step,  a  preliminary  outline  of  gross, 
critical  tasks  would  be  conducted. 
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Critical  task  analysis,  human  factors  (HF)  heuristic  review  of  TIAPS  and 
recommendations  for  research  and  development 

Discussion 


1.3  Objectives 

The  general  objectives  are: 

•  To  provide  a  base  reference  framework  for  existing  TIAPS  functions  under 
development  that  will  also  allow  future  functions  to  be  integrated 

•  To  identify  critical  operator  tasks  that  will  provide  a  focus  for  research  efforts  to 
provide  appropriate  HF  input  to  the  design  process. 

•  To  identify  areas  of  functionality  where  the  design  of  the  OMI  will  need  to  be 
sensitive  to  specific  operator  requirement  or  limitations 

•  To  identify  areas  of  the  TIAPS  OMI  that  will  require  particular  research  and 
development  effort. 


1.4  Glossary 

AAWC 

Anti  Air  Warfare  Co-ordinator 

ADAC 

Acoustic  Data  Analysis  Centre 

AOP 

Area  of  Operation 

ASW 

Anti-Submarine  warfare 

ASWC 

Anti-Submarine  Warfare  Commander 

C2 

Command  and  Control 

CANTASS 

CANadian  Towed  Array  Sonar  System 

CCS 

Command  Control  System 

CDC 

Computing  Devices  Canada 

CISTI 

Canada  Institute  for  Scientific  and  Technical  Information 

CO 

Commanding  Officer 

COP 

Common  Operational  Picture 

COTS 

Commercial  Off  The  Shelf 

CPF 

Canadian  Patrol  Frigate 

DCIEM 

Defence  and  Civil  Institute  for  Environmental  Medicine 

DII 

Defence  Information  Infrastructure 

DREA 

Defence  Research  Establishment  Atlantic 
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DV 

Data  Visualisation 

GCCS 

Global  Command  and  Control  System 

GIS 

Geographical  Information  System 

HF 

Human  Factors 

— 

MOP 

Measure  of  Performance 

MPA 

Maritime  Patrol  Aircraft 

_ 

NTDS 

Naval  Tactical  Display  Symbols 

NTIS 

National  Technical  Information  Service 

tmm, 

OMI 

Operator  Machine  Interface 

OODA 

Observe,  Orient,  Decide,  Act 

OR 

Operations  Room 

ORO 

Operations  Room  Officer 

PLA 

Passive  Localisation  Assistant 

RMP 

Recognised  Maritime  Picture 

SCS 

Sonar  Control  Supervisor 

SIMS 

Sonar  Integrated  Management  System 

SME 

Subject  Matter  Expert 

SonOp 

Sonar  Operator 

SOW 

Statement  of  Work 

— 

TASREPS 

Towed  Array  Sonar  Reports 

TasSup 

Towed  array  supervisor 

TG 

Task  Group 

TP 

Tactical  Picture 

— 

TMA 

Target  Motion  Analysis 

TIAPS 

Towed  Integrated  Active  Passive  Sonar 

UW 

Underwater 
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2.  Summary  Literature  review  of  OMI  issues 
for  sonar  systems. 


2.1  Background 

The  work  undertaken  below  is  guided  by  the  Statement  of  Work,  item  ft 6,  which  states: 

"Review  available  documentation  and  background  literature  relevant  to  the  design 
of  HMI's  for  sonar/combat  systems  and  prepare  a  short  summary  report  on 
literature  reviewed." 

The  present  literature  review  should  be  read  in  the  context  of  an  earlier,  more  detailed  review 
conducted  for  DREA  (Matthews,  Greenley  and  Webb,  1994),  which  contains  a  more  extensive 
discussion  of  the  literature. 

In  reviewing  the  scope  of  the  review  with  the  Scientific  Authority,  it  was  decided  that  a  limited 
search  be  also  conducted  in  the  area  of  data  visualisation,  since  there  was  a  likelihood  that  future 
sonar  and  combat  systems  would  embrace  aspects  of  data  fusion  and  other  aspects  of  data 
abstraction.  It  was  noted  that  existing  guidelines  that  were  available  did  not  provide 
recommendations  in  this  area.  A  second  outcome  of  the  review  of  the  scope  of  the  search  was 
the  decision  not  to  seek  or  review  generic  windowing  system  or  platform- independent  guidelines. 

2.2  Objectives 

The  overall  goals  of  the  literature  review  are  (1)  to  provide  relevant  documentation  for  system 
developers  to  consult  as  required  in  order  to  optimise  the  sonar  operator  interface  in  new  and 
emerging  systems  and  (2)  to  provide  a  basis  for  a  heuristic  review  of  the  TIAPS  OMI  currently 
under  development. 

2.3  Organisation  of  this  section 

A  complete  listing  of  all  of  the  relevant  references  that  were  obtained  and  examined  is  provided 
in  Annex  A. 

The  initial  section  describes  the  methodology  used  for  the  report,  followed  by  a  section  that 
provides  a  brief  commentary  upon  the  most  useful  subset  of  references  that  were  found.  These 
references  are  organised  into  the  following  sub-categories: 

•  Sonar  systems 

•  Military  combat  systems 

•  General  military  and  relevant  non-military  guidelines 

•  Data  visualisation 
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The  first  three  categories  represent  decreasing  levels  of  system  specificity  concerning  guidelines 
and  recommendations.  The  final  category  is  somewhat  different  in  that  it  contains  material  that 
may  be  of  relevance  at  any  level  of  specificity. 

After  reviewing  either  an  abstract  or  their  content,  papers  and  reports  listed  in  the  complete 
bibliography  that  were  generally  deemed  to  be  of  little  relevance  to  the  immediate  project  goals 
were  not  commented  upon  in  these  sections. 

The  literature  review  finishes  with  an  overall  summary  and  conclusions. 

2.4  Search  methodology 

The  aim  of  the  literature  review  was  to  locate  and  review  current  literature  in  two  areas: 

1)  Existing  human  factors  guidelines  or  research  reports  relevant  to  the  interface 
design  of  combat  systems,  in  particular  sonar  systems. 

2)  Literature  on  data  visualisation 

2.4.1  Databases  Searched 

The  searches  were  conducted  using  the  Canada  Institute  for  Scientific  and  Technical  Information 
CISTI  database  (cat.cisti.nrc.ca)  and  National  Technical  Information  Service  (NTIS) 
(www.ntis.gov)  as  well  as  a  library  catalogue  search  of  the  Trellis  system  through  the  University 
of  Guelph. 

NTIS 

NTIS  is  an  agency  for  the  U.S.  Department  of  Commerce’s  Technology  Administration.  It  is  the 
official  source  for  government  sponsored  U.S.  and  worldwide  scientific,  technical,  engineering 
and  business  related  information.  The  400,000  article  database  can  be  searched  for  free  at  the 
www.ntis.gov.  Articles  can  be  purchased  from  NTIS  at  costs  depending  on  the  length  of  the 
article. 

CISTI 

CISTI  stands  for  the.  It  is  the  library  for  the  National  Research  Council  of  Canada  and  a  world 
source  for  information  in  science,  technology,  engineering  and  medicine.  The  database  is 
searchable  on-line  at  cat.cisti.nrc.ca.  Articles  can  be  ordered  from  CISTI  for  a  fee  of 
approximately  $12. 

Trellis 

Trellis  is  the  catalogue  for  the  Tri-University  Group  (TUG)  of  universities.  It  contains 
catalogues  of  book  and  journal  sources  from  the  University  of  Guelph,  University  of  Waterloo 
and  Wilfred  Laurier  University  library  systems. 
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2.4.2  Keywords 

A  set  of  keywords  was  developed  with  the  goal  of  locating  literature  in  the  two  areas  described 
above. 

Keywords  intended  to  locate  literature  on  interface  guidelines  were  divided  into  four  categories. 
Category  1  related  to  the  sonar  environment,  category  2  was  “interface  related”,  category  3  was 
“user  related”  and  category  4  was  “guideline  related”. 

For  the  data  visualisation  area  of  the  search,  words  were  divided  into  two  categories,  Category  5 
was  “visualisation  related  words”  and  category  6  was  “modifiers” . 

The  words  in  each  category  are  listed  in  Table  1 

Table  1:  Keywords  used  for  literature  search 


Area  1-  Interface  guidelines 


Category  1 

Category  2 

Category  3 

Category  4 

Sonar  environment 

Interface  related 

User  related 

Guideline  related 

Sonar  OR  command 
and  control 

OR  C2  OR  C3  OR  C4  or 
C3I 

OR  information  systems 

Interface  OR  display  OR 
interaction 

User  OR  human 

OR  man-machine  OR 
human-computer  OR 
man-computer  OR 
human-machine  OR 

HCI  OR  HMI 

Guidelines  OR  rules  OR 
requirements 

OR  recommendations 

OR  design 

OR  specifications 

OR  combat  systems  OR 
combat  information 
center 

OR  OMI  OR  human 
systems  integration 

OR  standards 

OR  style  guide 

— 

OR  anti-submarine  OR 
ASW  OR  defense  OR 
defence  OR  navy  OR 
naval  OR  military  OR 
marine  OR  ship  OR 
operations  room  OR 
subsurface  war  OR 
subsurface  warfare 

OR  maritime 

... 

OR  submarine 

OR  NATO 

Area  2— Data  Visualisation 


Category  5 

Category  6 

Visualization 

Modifiers 

Visualization  or  visualisation 

information  OR  command  OR  data 
OR  battlespace  OR  sonar 
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2.5  Search  strategy 

The  initial  approach  to  setting  keyword  combinations  for  the  search  was  as  follows: 

Area  1:  Interface  Guidelines 
Search: 

Category  1  and  Category  2, 

Category  1  and  Category  3, 

Category  1  and  Category  4 
If  this  generated  too  many  results,  then  search: 

Category  1  and  Category  2  and  Category  3 
Category  1  and  Category  2  and  Category  4 
Category  1  and  Category  3  and  Category  4 
If  this  generated  too  many  results,  then  search: 

Category  1  and  Category  2  and  Category  3  and  Category  4 
Area  2-Data  Visualisation 
Search:  Category  5  and  Category  6 

In  practice,  because  many  of  the  categories  produced  few  or  no  results,  or  many  irrelevant 
results,  the  searches  were  combined  and  conducted  together.  For  guideline  related  references  the 
following  search  was  used: 

( Category  1  OR  Category  3)  AND  (Category  2  OR  Category  4)) 
and  for  data  visualisation  references,  the  following  search  was  used: 

(Category  5  OR  Category  6) 

2.6  Search  results 

The  relevant  items  selected  from  each  search  source  are  shown  below  in  Table  2  below. 

Table  2:  Numbers  of  articles  found  using  the  above  search  parameters. 

(Note:  the  first  number  is  the  total  number  of  articles,  second  number  is  those  deemed  to  be  relevant) 


Guideline- related 

V  lsuahsation-related 

CISTI 

371- >2 

388  —  >4 

NTIS 

200- >3 

200- >18 

Trellis 

22- >  8 

26 ->  10 

Total 

13 

32 
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Many  of  the  references  resulting  from  the  searches  were  determined  to  be  irrelevant,  either 
immediately  by  the  title  or  after  review  of  the  abstract.  Some  references  were  located  in  both 
CISTI  and  NTIS,  or  both  Trellis  and  CISTI.  In  the  above  Table  these  references  are  shown 
under  NTIS  or  Trellis,  and  not  under  CISTI.  The  NTIS  searches  were  limited  to  200  references 
because  of  the  nature  of  the  NTIS  search  interface. 

Most  of  the  references  located  through  CISTI  and  NTIS  were  gathered  from  the  DCIEM 
Scientific  Authority  or  through  the  DCIEM  library.  References  from  Trellis  were  gathered 
through  the  University  of  Guelph. 

2.7  Other  reference  sources 

In  addition  to  the  references  found  through  the  online  database  searches,  some  additional 
applicable  references  were  reviewed.  There  were  several  sources  for  these  references:  interface 
guideline  sites  on  the  World  Wide  Web,  references  already  available  in-house  at  Humansy.s,fe/?tf 
and  references  provided  by  navy  personnel  or  the  DCIEM  scientific  authority.  In  practice,  many 
of  these  latter  references  tended  to  be  more  relevant  to  the  goals  of  the  project  than  those  found 
by  the  keyword  search  and  served  as  the  basis  for  finding  additional  sources  through  the  usual 
"snowballing"  process. 

The  search  strategy  became  modified  somewhat  after  the  opportunity  to  review  at  first  hand  some 
aspects  of  the  prototype  TIAPS  functionality.  It  was  discovered  that  one  core  aspect  of  the 
TIAPS  interface  and  functionality  employed  a  tactical  display  on  which  processed  sonar 
information  could  be  displayed  alongside  other  elements  of  the  tactical  situation  and 
environmental  data.  Therefore,  late  in  the  search  it  was  decided  to  extend  the  search  in  a  limited 
manner  to  gather  information  on  already  available  guidelines  relevant  to  combat  tactical  displays. 
This  extended  search  was  conducted  exclusively  using  snowballing  methodology. 

2.8  Commentary  on  selected  references 

The  references  below  represent  a  selected  subset  of  the  references  in  the  Annex  A,  chosen  for 
their  appropriateness  to  the  goals  of  the  review.  In  the  case  of  the  section  on  data  visualisation, 
many  of  the  references  did  not  provide  any  usable  guidelines  or  data  that  would  be  of  value  for 
immediate  adoption  into  the  TIAPS  design  and  development  process.  However,  the  area  of  data 
visualisation  is  probably  going  to  be  of  key  importance  not  only  to  sonar  operators,  but  also  to 
other  navy  personnel  engaged  in  working  with  new  generations  of  combat  systems.  These 
systems  will  no  doubt  involve  functionality  that  incorporates  data  fusion,  data  modelling  and 
large-scale  data  management  in  support  of  new  approaches  to  enhance  military  decision  making. 
Therefore,  it  was  decided  to  provide  a  brief  overview  of  some  of  the  major  work  published  in  the 
area  of  data  visualisation  in  recent  years  to  provide  a  reference  base  for  scientists  and  system 
developers  who  are  beginning  to  think  about  issues  of  data  visualisation  in  combat  systems. 

In  each  sub-section  the  material  is  organised  alphabetically.  Papers  or  reports  of  particular 
importance  are  prefaced  with 
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2.8.1  Sonar  systems 

Benke,  K.  K.,  &  Hedger,  D.  F.  (1996).  Improving  Feature  Perception  in  Sonar  Displays  by 
Contrast  Normalisation  and  Enhancement.  Canberra,  Australia:  Defence  Science  and 
Technology  Organisation. 

This  paper  provides  methods  for  compressing  and  digitising  sonar  data  through  gamma 
compensation  to  optimise  luminance  profile  on  sonar  displays.  The  method  is  said  to  improve 
the  operator's  perception  of  seabed  features  and  improves  search  reliability  during  surveillance. 

Doll,  T.  J.,  &  Hanna,  T.  E.  (1989).  Effects  of  Bimodal  Displays  on  Sonar  Target  Detection. 
Groton,  CT,  USA:  Naval  Submarine  Medical  Research  Lab. 

This  report  examines  the  impact  of  supplementing  lofargram  type  displays  with  redundant 
auditory  signals  on  sonar  target  detection.  Finds  a  1 . 1  dB  improvement  for  the  bimodal  display 
format  and  some  reduction  of  the  effects  of  uncertainty  on  detection.  Enhanced  spatial 
compatibility  between  the  visual  and  auditory  displays  produced  no  measurable  effects.  But  this 
may  have  been  due  to  the  fact  the  type  of  compatibility  that  was  selected  had  not  been  optimised. 
Further  the  seemingly  more  compatible  relationship  between  a  dichotic  auditory  display  and  a 
visual  display  did  not  improve  performance  over  a  diotic  (less  compatible)  display. 

Douglas,  H.  J.,  &  Zannelli,  D.  (2000).  Display  and  Control  Commonality  Initiative  Among 
Undersea  Warfare  Sonar  Systems.  Newport,  RI:  Naval  Undersea  Warfare  Center. 

This  report  outlines  some  standards  initiatives  for  the  OMI  by  the  Sonar  Systems  in  Undersea 
Warfare  group  to  provide  commonality  across  systems.  Some  data  are  provided  on  user  testing 
of  interface  options  concerning  input  mode  and  menus.  Although  this  report  does  not  list 
recommenced  standards  it  does  provide  useful  references  to  some  standards  documentation. 

Galvin,  L.  F.  (1991).  Human  Factors  Engineering  in  Sonar  Visual  Displays.  Massachusetts 
Institute  of  Technology,  Cambridge,  MA,  USA. 

This  is  oriented  towards  designing  an  OMI  for  a  remotely  operated  underwater  vehicle.  Of 
interest,  but  perhaps  limited  value,  is  a  prototype  colour  scheme  to  code  altitude  (depth)  bands. 
However,  since  the  author  does  not  provide  photometric  values  for  the  coded  elements  this  may 
mean  that  it  will  be  difficult  to  adopt  the  coding  scheme  to  other  applications  and  display 
environments. 

Handbook5:  Guidelines  for  Maritime  Information  Management.  Management  of  Organic 
and  Non-Organic  Information  in  the  Maritime  Environment,  Command,  Control  and 
Communications  Committee,  AUSCANNZUKUS,  April  1997. 

This  document  provides  an  important  high  level  overview  of  generic  information  management 
needs  for  maritime  command  and  control.  Useful  sections  for  present  purposes  include: 

•  A  description  of  basic  naval  command  system  characteristics 

•  A  list  of  system  user  requirements 

•  Requirements  for  the  maritime  tactical  picture 
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•  Sensors  and  sensor  management 

•  Classification 

•  Track  quality  and  management 

•  Data  fusion 


Some  specific  points  of  reference  that  will  need  to  be  considered  in  developing  the  TIAPS  system 
in  conformity  with  the  guidelines  are: 

3.9.2. 2. a  Procedures  for  track  management 

3. 9. 3. 5  Sensor  management 

3.9.4  Classification  (in  particular  section  on  classification  confidence) 

3.9. 5. 3  Track  quality 

3 . 9 . 5 . 4  Factors  affecting  procedures 

3. 9. 6. 3  Data  confidence 

3.9.7  Data  fusion  (especially  sub-sections  7.4,  7.5,  7.6,  8.4) 

It  should  be  remembered  that  since  the  document  is  a  high  level  overview,  no  specific  guidelines 
are  provided  on  the  OMI  that  will  be  required  to  achieve  the  above. 


Holliday,  T.  M.  (1998).  Real-Time  3D  Sonar  Modeling  and  Visualization.  Unpublished 
Master's,  Naval  Postgraduate  School,  Monterey,  CA. 

This  thesis  discusses  mostly  technical  and  computational  issues  with  respect  to  transforming 
acoustic  data  into  3D  representations. 

The  section  on  visualisation  attempts  to  provide  some  guidance  on  how  to  map  high 
dimensionality  sonar  data  onto  two  dimension  displays  and  suggests  that  there  is  no  right  answer. 

Comment: 

Some  very  general  recommendations  are  made  on  mapping  that  are  probably  insufficiently 
detailed  to  be  of  immediate  utility  for  interface  design. 


Kobus,  D.  A.,  &  Lewandowski,  L.  (1991).  Reported  Modality  Preferences  of  Sonar 
Operators.  San  Diego,  CA:  Naval  Health  Research  Center. 

This  empirical  study  shows  that  sonar  operators  prefer  a  visual  over  an  auditory  presentation  of 
data,  and  believe  that  they  are  better  in  the  visual  mode.  This  corresponds  to  their  general 
modality  preferences  for  non-sonar  tasks.  Suggests  some  design  flexibility  to  allow  for  the 
minority  of  operators  who  prefer  the  auditory  mode. 

Manning,  R.  &  Lankester,  M.  Sonar  world  picture  compilation.  (U).  Proceedings  of  the 
TTCP  Symposium  Co-Ordinated  Maritime  Battlespace  Management ,  San  Diego,  CA,  May 
1999  (UK  Restricted) 
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This  text  provides  some  useful  descriptions  of  operator  aids  for  sonar  classification  to  reduce 
operator  workload  and  to  enhance  prioritisation  of  contacts  and  conflict  resolution. 

McFadden,  S.  M.,  Giesbrecht,  B.  L.,  &  Kalmbach,  K.  C.  (1995).  Effect  of  Monitor  Type 
and  Display  Orientation  on  the  Detection  of  Lines  on  a  Simulated  Passive  Sonar  Display. 
Downsview,  ON,  Canada:  Defence  and  Civil  Institute  for  Environmental  Medicine. 

McFadden,  S.  M.  Zulauf.,  M.  (1995).  Display  Factors  Affecting  The  Visibility  of  Information 
on  a  Simulated  Passive  Sonar  Display.  Downsview,  ON,  Canada:  Defence  and  Civil  Institute 
of  Environmental  Medicine. 

These  empirical  studies  show  that  displaying  lofargrams  with  the  time  history  along  (as  opposed 
to  current  practice  which  is  across,  i.e.  top  to  bottom)  the  scan  lines  yields  improved  operator 
detection  performance  (12-18%).  Result  holds  for  both  mono-  and  multi-chrome  monitors. 
Negligible  effects  of  reduced  luminance  output  (NB  -  this  was  only  degraded  20%  in  the  study). 

Undersea  Warfare  Sonar  Systems  Control  and  Display  Standards  and  Conventions 
(September  25,  1998).  Available:  www.ocwg.uswinfo.com. 

This  document  provides  a  comprehensive  catalogue  of  OMI  recommendations  for  undersea 
warfare  (USW  )  systems.  In  general,  the  overall  recommended  style  follows  standard 
commercial  practices  for  window  based  operating  systems  (e.g.  OSF  Motif,  Windows  NT)  and 
assumes  a  display  system  with  a  1280x1024  capability.  Much  of  the  specification  is  derived  from 
the  user  interface  specifications  for  Defence  Information  Infrastructure  (DII). 

Comment: 

This  will  be  an  essential  document  to  assist  the  Computing  Devices  Canada  Inc  (CDC)  design 
team  in  many  aspects  of  the  detailed  OMI  development  and  against  which  to  assess  the  degree  to 
which  TIAPS  meets  recommended  standards.  In  addition  to  providing  commonly  understood 
conventions  for  window  design,  navigation  and  dialog  boxes,  it  also  provides  specific  guidance 
on  USW  functions,  including  ship  data  and  sensors,  tactical  symbology  (MIL-STD  2525A), 
acoustic  cursors  and  acoustic  displays. 

Caveats  and  linutations 

1 .  The  guide  recommends  the  use  of  grayscale  only  for  lofargrams  -  hence  no 
colour  guidelines  are  provided 

2.  Colour  application  recommendations  for  display  elements  are  not  provided  in 
appropriate  photometric  units  (the  guide  only  provides  RGB  values  and  colour 
names). 

3.  No  specific  considerations  are  given  to  the  constraints  on  the  OMI  that  may  be 
produced  by  local  environmental  lighting. 

4.  No  considerations  are  given  to  support  for  the  user's  mental  model  in  switching 
between  various  display  modes. 
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5.  The  guide  recommends  against  the  use  of  "reverse  video"  for  text  on  the  grounds 
of  lower  legibility  and  increased  operator  fatigue.  Assuming  that  this  means  text 
characters  that  have  higher  luminance  than  the  background  (positive  contrast), 
this  recommendation  must  be  questioned.  The  statement  does  not  reflect  recent 
research  in  this  area,  which  has  shown  equivalent  legibility  for  positive  contrast 
displays.  Further,  when  using  coloured  text  and  coloured  backgrounds,  the  term 
reverse  video  is  inapplicable. 

6.  No  specific  guidelines  provided  on  appropriate  coloured  text  and  background 
combinations. (e.g.  with  delta  Yu'v’  colour  space  recommendations) 

7.  The  adherence  to  the  Motif/Windows  NT  style  for  the  application  of  colour  to 
window  elements  creates  problems  for  designing  a  colour  style  that  is  appropriate 
to  the  USW  operating  environment. 

8.  No  consideration  is  given  to  over-the-shoulder  viewing  needs  by  other  team 
members. 

Woollings  M.J.  Automatics  vs.  operators  in  active  sonar.  (U).  Proceedings  of  the  TTCP 
Symposium  Co-Ordinated  Maritime  Battlespace  Management,  San  Diego,  CA,  May  1999 
(UK  restricted). 

The  author  defines  the  major  problem  in  active  sonar  as  follows:  "  the  combat  system  will  never 
be  able  to  cope  with  the  tracks  produced  by  an  active  sonar  operating  in  littoral  waters  without 
an  intelligent  filter  acting  on  the  raw  sonar  data The  author  describes  a  simulation  model  to 
reduce  false  alarm  rates  while  maintaining  detection  and  provides  data  on  how  the  model 
compared  with  an  actual  operator. 

Comment: 

This  will  be  of  use  to  system  designers  who  are  engaged  in  implementing  automatic  detection 
algorithms  for  active  sonar. 

2.8.2  Military  combat  systems 

A  large  number  of  guidelines  and  research  reports  in  this  area  have  appeared  in  recent  years, 
some  developed  independently  by  separate  branches  of  the  military  or  independent  contractors 
and  others  developed  sequentially  by  the  US  military  to  rationalise  and  integrate  knowledge.  The 
majority  of  these  reports  provide  generic  guidelines  for  OMI  design  for  military  systems,  which 
is  not  the  primary  focus  of  the  existing  review  (i.e.  sonar  combat  systems).  Examples  of  these 
guidelines  are:  Department  of  Defense  Technical  Architecture  Framework  for  Information 
Management:  (1996),  Engel,  and  Townsend  (1989),  Carlow:  Human  Computer  Interface 
Guidelines  (1992).  These  may  be  generally  useful  as  a  reference  source  for  system  developers  of 
naval  combat  systems  and  defence  scientists  but  are  not  commented  upon  here. 

The  small  number  of  papers  that  are  commented  upon  on  this  section  provide  some  specific 
detailed  information,  not  to  be  found  in  guidelines,  and  deemed  to  be  directly  relevant  to  OMI 
issues  in  combat  systems  design. 
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Hair,  D.  C.  P.,  K.  (1993).  User  Interface  Issues  in  Real  Time  Decision  Support  Systems.  San 
Diego,  CA:  Naval  Command,  Control  and  Ocean  Surveillance  Center. 

This  research  was  part  of  the  TADMUS  project.  For  real  time  decision  making  support, 
automatic  critiquing  of  decisions  is  seen  as  a  preferred  approach  over  decision  makers  interacting 
with  the  system.  Tools  have  been  developed  to  support  both  recognition  primed  decision  making 
(RPD)  or  explanation  based  decision  making.  The  goal  is  to  provide  information  in  a  way  that 
matches  the  user's  decision  making  approach.  On  the  basis  of  limited  empirical  studies,  the 
author  suggests  eliminating  features  of  decision  support  that  require  frequent  user  interaction. 

This  results  in  "severe  simplification  of  tool  capabilities". 

An  alternate  approach  is  to  incorporate  a  model  of  the  user  into  the  system.  The  model  will  then 
analyse  the  user's  information  needs,  supply  the  appropriate  information  and  warn  of  possible 
errors.  At  present,  this  approach  is  not  being  explored. 

The  author  is  also  trying  an  approach  which  (1)  structures  displays  in  a  manner  that  provides 
suggestions  about  alternative  conclusions,  or  (2)  finds  template  matches  appropriate  to  RPD  or 
(3)  provides  a  record  of  historical  information  to  prevent  users  from  losing  track  of  relevant  data. 

The  overall  goal  is  to  reduce  negative  effects  of  cognitive  biases  in  decision  making. 

Comment: 

References  in  the  area  of  real  time  decision  support  should  probably  be  followed  up  since  this 
may  be  of  value  in  assisting  design  for  some  of  the  higher  level  OMI  functions  that  are  likely  to 
emerge  for  TIAPS  and  other  combats  systems. 

Laxar,  K.,  &  Van  Orden,  K.  F.  (1994).  Symbology  Optimization  and  Display  Assessment 
(SODA)  Project::  Minimum  Size  for  Color  Coded  NTDS  and  NATO  Symbols  (  NSMRL  Report 
1194):  Naval  Submarine  Medical  Research  Laboratory. 

Using  3  symbol  sizes:  19/22,  28/32,  38/40  (NTDS/NATO)  arcmin  in  a  multidistractor  search  task 
(10  or  40). For  NATO  symbols  search  time  for  19'  increased  by  about  23%  over  28'  targets  and 
57%  over  38'  targets. 

For  Naval  Tactical  Display  symbols  (NTDS)  search  time  for  22'  increased  by  about  25%  over 
32'  targets  and  37%  over  40'  targets. 

NTSD  smallest  targets  faster  by  about  60%  faster  than  NATO  and  fewer  errors. 

Effect  of  distractor  set  size  much  larger  for  NATO  targets  and  small  targets. 

Limitations: 

Relatively  simple  symbol  format  (no  additional  codes  or  text) 

Ambient  illumination  values  and  luminance  values  not  provided,  hence  the  user  cannot  calculate 
delta  Yu'v'  which  is  important  for  establishing  generality  of  the  result  to  other  colour /luminance 
conditions. 
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Osga,  G.  (1995).  Combat  Information  Center  Human-Computer  Interface  Design  Studies 
(Final  TD  2822).  San  Diego,  CA:  Naval  Command,  Control  and  Ocean  Surveillance  Center 
RDT&E  Division. 

This  report  provides  a  comprehensive  review  analysis  of  the  AEGIS  OMI  in  the  context  of  the 
Anti  Air  Warfare  Co-ordinator  (AAWC)  position.  The  report  outlines: 

•  Detailed  recommendations  on  general  and  specific  design  concepts  with  respect  to 
displays,  controls  and  workstation  configuration 

•  Useful  methods  on  test  and  evaluation 

•  Selected  human  performance  criteria 
Comment: 

This  report  provides  an  essential  guide  against  which  to  evaluate  current  systems  as  well  as 
informing  the  design  of  future  systems.  Many  of  the  suggested  design  concepts  may  serve  as 
useful  models  and  examples  for  the  TIAPS  OMI. 

The  strengths  of  the  report  are  in  its  careful  analytic  approach  to  the  problem,  using  data  from 
task  analysis  to  inform  design  decisions  and  evaluating  prototype  design  options  using  valid  tasks 
and  empirical  data. 

Particularly  useful  sections  pertain  to: 

•  Displays  for  system  status 

•  Variable  action  buttons 

•  Touch  panel  design 

•  Comparison  of  input  methods  (trackball,  mouse,  touchscreen) 

•  Workstation  configuration 

•  Tactical  displays  and  symbology 

Osga,  G.,  &  Keating,  R.  (1994).  Usability  Study  of  Variable  Coding  Methods  for  Tactical 
Information  Display  Visual  Filtering  (Final  TD  2628).  San  Diego,  CA:  Naval  Command, 
Control  and  Ocean  Surveillance  Center  RDT&E  Division. 

Variable  coded  symbology  is  seen  as  a  way  of  providing  redundant  colour  and  shape  coding  to 
facilitate  data  extraction  from  complex  tactical  displays.  The  additional  coding  served  as  a  way 
for  operators  to  rapidly  selectively  filter  displayed  elements  and  enhance  speed  and  accuracy  of 
performance. 

Operators  performed  a  task  involving  a  tactical  display  with  many  tracks  for  which  they  were 
required  to  develop  filters  to  categorise  track  types.  High  face  validity  to  actual  tactical  displays 
is  apparent. 

Comment: 

The  methodology  may  be  useful  for  future  studies  to  evaluate  data  fusion  techniques. 
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Van  Orden,  K.  F.,  Nugent,  W.,  La  Fleur,  B.,  &  Moncho,  S.  (1999).  Assessment  of  Variable 
Coded  Symbology  Using  Visual  Search  Performance  and  Eye  Fixation  ( Final  99-4).  San 
Diego,  CA:  Naval  Health  Research  Centre. 

Found  faster  visual  search  and  fewer  distractor  errors  with  either  colour  coded  NTDS  symbols  or 
prominent  colour  block  filled  NATO  symbols.  Recessed  NTDS  gray  symbols  produced  the 
slowest  times.  (NB  best  case  to  worst  case  is  2.1  secs  versus  4.2  secs.  NATO  colour  filled 
superior  to  next  best  condition  by  about  38  % . 

Limitations: 

No  photometric  data  are  provided. 

2.8.3  General  military  and  relevant  non-military  publications 

Since  this  is  a  very  broad  category  and  the  large  number  of  published  articles  may  only  have 
limited  direct  relevance  to  the  goals  of  this  project,  search  in  this  category  was  given  a  lower 
priority  and  strictly  limited  to  recent  publications  that  would  be  of  immediate  use  to  system 
developers. 

Brasseur,  P.  D.,  &  Nihoul,  J.  C.  J.  (1993,  May  1993).  Data  assimilation  :  Tools  for 
Modelling  the  Ocean  in  a  Global  Change  Perspective ,  Liege,  Belgium. 

This  provides  mostly  technical  aspects  of  calculating  and  displaying  ocean 
temperature/space/depth  information,  but  some  interesting  graph  examples  of  modelling  complex 
data. 

Levkowitz,  H.  (1997).  Color  Theory  and  Modeling  for  Computer  Graphics,  Visualization,  and 
Multimedia  Applications.  Boston:  Kluwer  Academic  Publishers. 

This  is  a  useful  reference  source  for  calibration  of  colour  displays,  metrics  for  creating 
perceptually  uniform  colour  scales  and  generating  displays  whose  colours  are  stable  and  device 
independent. 

Some  empirical  data  on  "blob  detection"  show  that  monochromatic  grey  displays  yield  superior 
performance  to  colour. 

2.8.4  Data  Visualisation 

Note:  abbreviated  to  DV  in  the  following  section 

Bajaj,  C.  (1999).  Data  Visualization  Techniques.  Chichester  ;  New  York:  Wiley. 

Comment: 

The  contributed  chapters  all  deal  with  technical  aspects  of  generating  visualised  representations 
from  data  sources.  There  is  no  discussion  of  guidelines  for  interfaces  or  which  representations 
are  better  suited  for  different  types  of  data  and  applications,  nor  discussion  of  human 
comprehension  and  understanding.  The  book  does  provide  a  wealth  of  coloured  examples  of 
different  visualisation  representations. 
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Of  interest,  the  author  states  some  fundamental  principles  or  goals  that  should  drive  visualisation. 
These  are: 

•  Deeper  understanding  of  data 

•  Rapid  pruning  of  useless  data 

•  Rapid  focus  on  necessary  information 

•  Comprehending  the  science  or  circumstances  behind  the  data 

•  Use  of  motion  and  other  techniques  such  as  simulated  depth,  surface  texture  and 
colour  to  bring  out  hidden  or  important  aspects  of  data. 

•  Use  of  motion  for  dynamic  data. 

•  Provide  interactive  manipulation  of  data. 

Earnshaw,  R.  A.,  &  Wiseman,  N.  (1992.).  An  introductory  guide  to  scientific  visualization. 
Berlin  ;  New  York:  Springer-Verlag. 

This  text  provides  some  goals  of  DV  which  include: 

•  Visual  data  analysis 

•  Insights  into  high  dimensional  data 

•  Comprehension  of  large  data  sets 

But  no  HF  guidelines  or  recommendations  are  provided  on  how  to  achieve  these. 

While  the  book  does  provide  some  good  colour  examples  of  various  visualisation  techniques,  the 
bulk  of  it  is  largely  a  compilation  of  descriptions  of  various  commercial  DV  packages. 

Gershon  N.  Battlespace  Visualisation  Issues.  NATO  RTO  IST-20/WS-002  Workshop 
"Visualisation  of  Massive  Military  Datasets",  June  2000,  Defence  Research  Establishment 
Valcartier,  Quebec,  Canada. 

This  paper  presents  a  brief  conceptual  overview  of  the  major  visualisation  issues  relating  to 
battlespace  visualisation.  There  is  no  specific  military  focus  and  the  only  information  available 
in  the  paper  is  a  single  figure  showing  the  various  issues,  without  any  accompanying  text 
narrative.  Note:  the  paper  was  reviewed  as  a  Powerpoint  printout  and  no  accompanying,  detailed 
text  narrative  was  available. 

Heamshaw,  H.  M.,  1948-,  Unwin,  D.  J.,  &  Information,  A.  f.  G.  (1994).  Visualization  in 
geographical  information  systems.  Chichester,  West  Sussex,  England  ;  New  York. 

While  this  book  is  generally  oriented  towards  GIS  it  does  provide  some  concepts  of  where  DV 
might  be  generically  useful.  These  are: 
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•  Representation  of  time:  duration,  rate  of  change,  slow  and  fast  constants, 
chronological  order,  attribute  order. 

•  Representation  of  data  validity  and  uncertainty,  (data  quality) 

•  Interaction  with  data 

•  Multiple  views  for  multiple  users 

The  book  does  contain  a  modest  section  on  HF  issues  in  DV;  overall  it  provides  a  disappointingly 
low  level  review  of  underlying  visual  and  psychological  processes. 

Some  of  the  general  HF  recommendations  for  data  interactivity  are: 

•  Provide  fast  and  rapidly  updated  representations  in  response  to  user  input. 

•  Ensure  data  are  displayed  in  concepts  understood  by  user. 

•  Provide  easy  manipulation  of  properties  of  representation. 

•  Use  of  screen  space  optimally 

•  Provide  basic  tools  such  as:  data  probe  (for  local  exploration  and  annotation),  local 
viewing,  ruler. 

•  Use  "natural  display  mappings". 

Hollands,  J.G.  Command  Visualisation.  NATO  RTO  IST-20/WS-002  Workshop 
"Visualisation  of  Massive  Military  Datasets",  June  2000,  Defence  Research  Establishment 
Valcartier,  Quebec,  Canada. 

This  paper  provides  a  useful  overview  of  how  visualisation  can  support  the  understanding  of  data 
in  a  variety  of  command  contexts  and  demonstrates  how  multiple  views  and  pictorial 
representations  improve  upon  standard  tabular  data  formats.  The  focus  of  the  paper  is  the 
process  of  developing  a  command  visualisation  testbed  to  enhance  planning  and  operational 
functions.  The  paper  provides  some  examples  of  avoiding  designs  that  reduce  perceptual  bias 
and  enhance  the  representation  of  the  user's  mental  model.  Note:  the  paper  was  reviewed  as  a 
Powerpoint  printout  and  no  accompanying,  detailed  text  narrative  was  available. 

IEEE  Visualization  1998,  IEEE  Visualization  1999. 

1998  IEEE  Conference  on  Information  Visualization  :  An  International  Conference  on 
Computer  Visualization  &  Graphics  :  Proceedings(July  29-31, 1998).,  London,  England. 

1999  IEEE  Symposium  on  Information  Visualization  (InfoVis'99)  :  proceedings(October  24- 
29,  1999).,  San  Francisco,  California. 

These  proceedings  provide  mostly  technical  papers  on  numerical  methods,  algorithms  and 
different  display  formats  for  DV.  No  HF  content  was  found  and  there  were  no  specific  C2 
examples. 
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Keller,  P.,  &  Keller,  M.  (1993).  Visual  Cues  :  Practical  Data  Visualization.  Los  Alamitos, 

CA:  IEEE  Computer  Society  Press. 

This  is  a  primer  for  designers  involved  in  generating  data  images.  It  provides  a  simplistic 
overview  of  basic  perceptual/display  issues.  Some  general  guidelines  on  use  of  colour  are 
provided  (pp28-31).  The  balance  of  the  book  contains  a  large  number  of  specific  examples  of 
different  applications. 

The  text  provides  a  taxonomy  of  usages  to  which  DV  may  be  applied;  for  example:  to  identify, 
locate,  distinguish,  categorise,  cluster,  rank,  compare,  associate  and  correlate  data.  The  authors 
suggest  that  where  competing  goals  would  lead  to  different  DV  solutions,  the  goals  should  be 
rank  ordered. 

Mulheam,  J.F.,  Encamaceo,  M.,  Shane,  R.T.  A  collaborative  visualization  environment  for 
submarine  command  and  control.  Proceedings  of  the  TTCP  Symposium  Co-Ordinated 
Maritime  Battlespace  Management,  San  Diego,  CA,  May  1999 

This  paper  provides  some  general  concepts  concerning  3D  visualisation  of  undersea  battlespace. 

It  identifies  some  fundamental  user  requirements,  which  are:  (1)  a  realistic  display  which  is  not 
defined  by  the  authors  in  any  detail,  however  in  other  sections  of  the  paper  they  indicate  that  the 
display  should  comprise  a  3-D  display  of  perceived  undersea  battlespace  with  bathymetry, 
detection/counter  detection  regions  and  contacts  volume  of  uncertainty)  (2)  the  ability  for  the  user 
to  differentiate  between  realistic  and  approximated  display  and  (3)  the  user  to  be  aware  of 
imprecision  of  approximated  data. 

NATO  IST-13/TG-002.  Visualisation  in  Massive  Military  Datasets. 

This  report  represents  a  comprehensive  review  of  visualisation  issues  relating  to  military  systems 
generally,  not  just  large  datasets  as  suggested  by  the  title.  The  value  of  this  report  is  that  it  takes 
a  human  factors  perspective  of  the  issues  rather  than  looking  at  the  underlying  technology 
required  to  support  visualisation. 

The  report  commences  by  outlining  a  "reference  model"  for  visualisation.  This  shows  the  critical 
role  to  be  played  by  the  visualisation  process  (the  what)  as  a  means  of  translating  sensor,  data  or 
other  processed  information  through  computing  engines  (the  how)  to  yield  human  understanding 
as  a  basis  for  action  (the  why).  Among  the  examples  of  computer  aids  to  visualisation  provided 
in  the  first  chapter,  there  is  a  useful  illustration  of  how  passive  sonar  data  may  be  more  readily 
understood  using  a  an  iso-surface  representation  of  underwater  topography  and  a  school  of  fish. 
Further,  it  is  suggested  that  the  task  of  the  sonar  operator  could  be  enhanced  by  the  provision  of 
improved  visualisation  methods  to  allow  for  the  integration  across  the  four  dimensions  of  sonar 
data. 

Chapter  2  provides  an  overview  of  selected  human  factors  issues  in  visualisation  and  represents  a 
useful  reference  for  design  engineers  by  drawing  attention  to  the  underlying  human  information 
processing  requirements  that  should  drive  the  technology  of  data  visualisation.  Major  areas 
covered  are  human  sensory  and  processing  limitations  and  the  four  major  ways  in  which  humans 
use  their  sensory  data.  These  are  controlling/monitoring,  alerting,  searching  and  exploring. 

Each  of  these  topics  is  examined  at  some  depth  and  useful  examples  are  provided.  A  major 
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section  of  the  chapter  is  devoted  to  an  examination  of  ways  in  which  data  displays  may  be 
mapped  to  human  sensory  systems  covering  topics  such  as  icon  maps,  symbols,  patterns  and 
clutter  and  reaching  into  more  abstract  representations  involving  metaphor  and  3d  representation. 

Chapter  3  examines  various  data  types  and  how  they  may  be  presented.  Six  major  dimensions  of 
data  types  are  suggested: 

1.  Data  acquisition  -  where  are  the  data  required,  relative  to  when  the  display  is 
needed? 

2.  Data  sources  -  is  there  a  single  source  or  more  than  one  independent  source  of  data? 

3 .  Data  choice  -  can  the  user  choose  the  data  to  be  acquired? 

4.  Data  identification  -  how  are  the  individual  data  elements  identified,  by  location  or  by 
label? 

5.  Data  values  -  what  kinds  of  values  can  the  data  have,  analogue  or  categorical? 

6.  Data  inter-relations  -  how  does  one  data  element  relate  conceptually  to  others?  Does 
the  value  of  one  affect  the  meaning  of  another?" 

Illustrations  and  examples  are  provided  for  each  data  dimension. 

The  latter  half  of  the  chapter  looks  at  ways  in  which  different  types  of  displays  (display  timing, 
data  selection,  data  placement  and  data  values)  may  be  matched  onto  the  data  categories,  using 
"natural"  mappings  or  more  abstract  cognitive  transformations. 

Chapter  4  provides  an  overview  of  some  specific  military  applications  including  C2  information 
systems,  network  monitoring,  event  stream  analysis,  task  analysis,  representation  of  text  and 
passive  sonar.  The  C2  section  outlines  the  standard  OODA  loop  (observe,  orient,  decide,  act) 
and  integrates  this  process  with  the  four  modes  of  data  visualisation  outlined  previously.  An 
example  is  provided  of  how  data  visualisation  through  an  iconic  tactical  map  may  assist  the  task 
of  assessing  danger  over  a  two  dimensional  spatial  area.  The  other  section  of  primary  interest  for 
present  purposes  concerns  issues  surrounding  the  visualisation  of  passive  sonar  data.  In  this 
section,  an  analysis  of  the  sonar  operator's  visualisation  requirements  is  discussed  in  the  context 
of  the  four  modes  of  using  sensory  data. 

Chapter  5  is  of  perhaps  less  relevance  for  present  purposes,  however,  it  provides  an  excellent 
overview  of  generic  human  factors  issues  in  interface  design. 

Chapter  6  represents  some  core  concepts  for  design  for  visualisation  by  providing  the  link 
between  design  approaches  for  data  presentation  and  manipulation  with  the  taxonomy  of  the  six 
data  dimensions.  The  chapter  outlines  requirements  for  data  presentation  systems  and  looks  at 
issues  such  as  fisheye  views,  attentional  focus  and  navigation.  Basic  functions  performed  on  the 
data  include  selection,  organisation,  manipulation  and  arranging.  Other  than  the  fisheye 
approach,  few  additional  concrete  examples  are  provided  of  specific  ways  to  optimise  the  data 
representation. 

Chapter  7  provides  examples  of  a  number  of  visualisation  applications  and  techniques.  Of  most 
relevance  to  present  purposes  are  the  examples  of  the  German  xIRIS  system  for  assisting 
situation  visualisation  and  assessment  and  the  UK  Master  Battle  Planner,  although  these  are  more 
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generally  useful  from  a  broad  C2  perspective  rather  than  impacting  directly  on  design  for  sonar 
systems. 

Although  not  the  focus  of  the  present  literature  analysis,  it  should  be  noted  that  Chapter  8 
provides  an  excellent  overview  of  performance  measurement  issues  in  data  visualisation.  This 
chapter  may  serve  some  future  use  in  the  development  of  specific  MOPs  to  evaluate  how 
effective  data  visualisation  approaches  may  be  compared  against  existing  systems. 

Chapters  9  and  10  summarise  conclusions  and  make  broad  recommendations  for  researchers, 
developers  and  the  military. 

Post,  F.  H.,  &  Hin,  A.  J.  S.  (1992).  Advances  in  Scientific  Visualization.  Berlin:  Springer- 
Verlag. 

This  has  limited  usefulness;  it  provides  a  collection  of  examples  of  applications  using  DV 
methods,  none  relevant  to  the  present  context. 

Sherr,  S.  (1998).  Applications  for  Electronic  Displays:  Technologies  and  Requirements.  New 
York:  John  Wiley  &  Sons,  Inc. 

Most  of  the  contents  are  not  relevant  for  present  purposes.  The  book  contains  mostly  derived  data 
that  is  repackaged  for  design  engineers  for  display  systems.  However,  there  are  useful  summaries 
on  pp. 340-341  on  display  technology  characteristics  and  display  requirements  for  different 
applications. 

Vernik,  R.  A  Proposed  Reference  Model  Framework  for  Applying  Computer-Based 
Visualisation  in  C3I.  NATO  RTO  IST-20/WS-002  Workshop  "Visualisation  of  Massive 
Military  Datasets",  June  2000,  Defence  Research  Establishment  Valcartier,  Quebec, 

Canada. 

This  paper  provides  a  broad  conceptual  approach  to  applying  visualisation  methods  to  the  full 
range  of  C3I  issues.  Of  specific  interest  are  the  sections  on  visualisation  approaches  and  their 
effectiveness  in  a  domain  context.  Specific  effectiveness  criteria  are  provided.  The  bulk  of  the 
paper  deals  with  an  example  of  an  asset  visualisation  tool  for  the  air  defence  ground 
environment.  Note:  the  paper  was  reviewed  as  a  Powerpoint  printout  and  no  accompanying, 
detailed  text  narrative  was  available. 

Wilson,  K.  G.  (1993).  Synthetic  Battlebridge:  Information  Visualization  and  User  Interface 
Design  Applications  in  a  Large  Virtual  Reality  Environment.  Unpublished  Master  of  Science 
in  Computer  Systems,  Air  Force  Institute  of  Technology  Air  University. 

In  spite  of  the  intriguing  title,  this  thesis  is  mostly  a  discussion  of  technical  aspects  of  software 
for  building  a  training  simulator  for  command  decision  making. 
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Wojszynski,  T.  G.  (1992).  Scientific  Visualization  of  Volumetric  Radar  Cross  Section  Data. 
Unpublished  Master  of  Science  in  Electrical  Engineering,  Air  Force  Institute  of  Technology 
Air  University. 

This  thesis  is  mostly  oriented  towards  the  development  of  algorithms  for  visualising  radar  cross 
sectional  data.  Some  of  the  techniques  for  applying  colour,  lighting  and  orientation  may  be 
transferable  to  some  sonar  applications. 

Wright  W.  (2000)  Visualisation  for  Sonar  Tactic  Decision  Aids.  NATO  RTO  IST-20/WS-002 
Workshop  "Visualisation  of  Massive  Military  Datasets",  June  2000,  Defence  Research 
Establishment  Valcartier,  Quebec,  Canada. 

This  paper  explores  some  useful  concepts  to  enhance  the  visualisation  of  environmental  data  to 
assist  the  more  rapid  assessment  of  the  underwater  situation  and  to  aid  tactical  decision  making  at 
the  ASW  command  level.  Concrete  examples  of  new  display  formats  to  portray  selected  aspects 
of  the  underwater  environment,  including  a  3d  environment  view,  and  2d  windows  showing 
range,  planning  and  analysed  acoustic  volume  views.  The  paper  represents  work  in  progress 
rather  than  a  definitive  overview  of  the  issues.  Note:  the  paper  was  reviewed  as  a  Powerpoint 
printout  and  no  accompanying,  detailed  text  narrative  was  available. 

2.9  Summary  and  conclusions 

The  search  failed  to  produce  a  large  number  of  recent  references  that  were  strictly  pertinent  to 
the  design  of  sonar  combat  systems,  as  might  have  been  expected.  The  document  that  probably 
comes  closest  to  providing  the  most  comprehensive  source  of  information  that  will  be  useful  to 
system  developers  is  Handbook  5  -  Guidelines  for  Maritime  Information  Management. 
However,  this  provides  a  high  level  analysis  of  requirements  and  does  not  provide  details  of  what 
specific  forms  of  OMI  will  be  required.  More  detailed  recommendations  on  OMI  issues  relevant 
to  sonar  combat  systems  can  be  found  in  the  report  Combat  Information  Center  Human- 
Computer  Interface  Design  Studies. 

It  was  hoped  to  find  more  papers  on  design  guidelines  for  data  visualisation,  for  data  fusion  and 
generic  data  management  and  possibly  for  sonar  data  displays  specifically.  However,  this  was 
not  the  case.  While  there  continues  to  be  research  into  optimising  the  display  of  processed  sonar 
data  and  the  way  sonar  operators  analyse  such  data,  the  search  revealed  that  little  had  been 
published,  until  fairly  recently,  concerning  the  design  and  use  of  automated  aids  to  sonar 
detection.  It  should  be  remembered  that  initially  the  search  was  focussed  on  sonar  combat 
systems  and  data  visualisation  in  the  hope  that  this  would  uncover  all  of  the  relevant  material. 

Somewhat  late  in  the  search  process,  it  was  learned  that  the  TIAPS  functionality  employed  a 
tactical  overview  display  on  which  processed  sonar  data  could  be  presented.  The  subsequent 
search  for  reference  literature  on  tactical  displays  revealed  a  number  of  relevant  original  research 
reports  as  well  as  guidelines  that  will  be  of  direct  relevance  to  system  design  and  heuristic 
evaluation  of  prototypes.  Examples  of  these  reports  are:  Undersea  Warfare  Sonar  Systems 
Control  and  Display  Standards  and  Conventions  (1998,),  Manning  and  Lankester  (1999), 
Mulhearn,,  Encarnaceo,,  and  Shane  (1999),  Osga,  (1995)  and  Osga  and  Keating,  (1994). 
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The  preliminary  function  analysis  of  the  TIAPS  (see  section  4.6.2  and  following)  system  revealed 
a  number  of  OMI  issues  that  had  not  been  anticipated  at  the  start  of  literature  search  and  review 
process.  These  included:  operator  interaction  with  automated  systems,  how  operators  work  with 
environment  and  propagation  models  and  how  the  role  of  the  sonar  operators  may  evolve  from 
the  roles  of  primary  target  classification  and  localisation  to  managers  and  interpreters  of  the 
output  of  automated  aids  in  these  areas.  The  search  produced  only  one  sonar  relevant  reference 
in  this  area  and  this  paper  underlined  some  fundamental  issues  in  working  with  automated  aids. 
Whether  or  not  there  is  an  established  or  emerging  literature  in  the  sonar  domain  in  the  above 
areas  remains  to  be  seen,  however  there  may  be  some  value  in  extending  a  future  literature 
review  to  examine  how  these  issues  have  been  approached  in  other  domains.  In  particular,  the 
nuclear  industry  may  be  a  useful  source  of  material  concerning  operator  interaction  with  (and 
trust  in)  automated  systems,  decision  support  systems  for  complex  data  management  and  possibly 
data  fusion. 

The  general  literature  that  was  found  through  keyword  search  in  the  field  of  data  visualisation 
was  for  the  most  part  disappointingly  inappropriate  for  present  purposes.  It  comprised  largely  of 
demonstrations  of  data  visualisation  across  a  variety  of  applications  with  particular  emphasis  on 
the  technical  of  presenting  data  (e.g.  algorithms,  software  methods).  Some  of  these 
demonstrations  revealed  potentially  useful  approaches  that  might  be  adapted  for  sonar  systems. 
Few  papers  dealt  with  HF  issues  for  data  visualisation.  Typically,  those  that  did  presented  the 
material  at  a  somewhat  shallow  level,  garnishing  known  recommendations  from  standard  OMI 
guidelines  with  little  original  research  in  evidence.  A  few  reports  identified  some  generic  user 
goals  for  data  visualisation. 

The  most  promising  source  of  literature  on  data  visualisation  for  military  contexts  was  found  at 
the  NATO  RSG  Data  Visualisation  website.  This  source  provides  links  to  ongoing  NATO  study 
group  reports  as  well  as  to  recent  conferences  specifically  directed  at  visualisation  of  military 
data.  The  overall  NATO  RSG  report  provides  an  excellent  framework  for  an  analysis  of 
visualisation  issues  and  will  be  of  value  to  system  designers  who  wish  to  gain  a  better 
understanding  of  how  human  factors  issues  need  to  be  considered  in  the  design  of  systems  with 
enhanced  data  visualisation  capabilities.  The  taxonomies  of  human  data  usage,  of  types  of  data 
and  the  mapping  of  these  two  concepts  provide  a  good  starting  point  for  system  designers  to 
frame  basic  questions  about  how  to  implement  visualisation  for  any  specific  design  context.  It  is 
highly  recommended  that  system  designers  consult  this  reference  source  before  considering  the 
specific  ways  in  which  they  expect  to  implement  visualisation. 

The  recent  annual  conferences  on  data  visualisation  in  military  contexts  provide  both  useful 
examples  of  conceptual  analyses  of  military  C2  information  needs  as  well  ongoing  specific 
examples  of  implementations  of  visualisation  approaches  to  military  contexts.  Of  particular 
interest  is  the  paper  of  Wright  (2000)  that  provides  concrete  examples  of  underwater  data 
modelling  and  visualisation  of  the  sonar  tactical  environment. 

In  conclusion,  a  limited  number  of  references  were  found  that  will  assist  either  system  designers 
in  developing  the  OMI,  or  provide  a  basis  for  a  heuristic  HF  review  of  emerging  TIAPS 
prototypes.  Most  of  these  references  pertain  to  the  design  of  symbology  and  overlays  for 
maritime  tactical  displays.  Limited  specific  HF  guidelines  were  found  for  data  visualisation  or 
data  fusion  that  were  relevant  (or  could  be  adapted)  to  sonar  systems. 
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In  view  of  the  enhanced  role  to  be  played  by  automatic  detection  and  tracking  processes  in 
TIAPS,  it  is  recommended  that  an  additional  limited  literature  search  be  conducted  to  review 
potentially  relevant  material  concerning  operator  interaction  with  automated  systems.  Issues  to  be 
explored  include  operator  trust,  setting  and  interpreting  parameters  for  automated  algorithms  and 
possibly  automated  decision  support  in  military  combat  systems. 


Page  24  Humansystems  Incorporated 

Final  Report  HF  review  of  OMI  for  Sonar/Combat  Systems  under  Development  at  DREA 


3.  Extension  of  the  existing  function  analysis 
of  CANTASS 


3.1  Introduction 

This  section  of  the  report  fulfils  SOW  item  4  by  providing  an  extension  to  the  YARD  functional 
analysis  based  upon  the  current  operational  usage  of  CANTASS.  The  revised  function  flow 
diagrams  and  descriptions  for  new  functions  are  shown  in  Annex  B. 

3.2  Limitations 

The  information  provided  is  based  upon  interviews  with  three  instructors  experienced  in 
CANTASS  and  observations  of  the  training  simulator  made  during  a  one-day  visit  to  the 
Underwater  Warfare  School  in  Halifax.  The  information  pertains  only  to  the  functions 
performed  by  the  Sonar  Control  Supervisor  (SCS)  and  sonar  operators  in  the  conduct  of  passive 
sonar  operations.  As  such,  it  excludes  the  following: 

•  functions  associated  with  active  sonar 

•  target  motion  analysis 

•  tactical  correlation  and  integration  of  sonar  information  at  the  level  of  the  Anti- 
Submarine  Warfare  Commander  (ASWC) 

•  all  system  administration  and  maintenance  functions. 

3.2.1  Suggested  modifications  to  YARD  function  analysis 

The  overall  context  of  the  YARD  analysis  is  a  “generic  anti-submarine  warfare  (ASW)  mission” 
i.e.  monitoring,  identification,  and  tracking  sub-surface  targets  of  interest,  but  not  engagement. 
Engagement  would  normally  be  conducted  by  another  asset  (helo,  Maritime  Patrol  Aircraft 
(MPA),  or  ship  without  CANTASS  streamed).  Information  gathered  during  the  visit  suggests 
that  there  are  two  new  types  of  goals/tasks  that  do  not  fit  exactly  within  this  broad  definition. 
Also  we  have  learned  from  our  previous  cognitive  task  analysis  (Matthews,  Webb  and 
Bryant,  1999)of  the  Operations  Room  Officer  (ORO)  position  that  missions  in  collaboration  with 
other  authorities  may  be  on  the  increase.  These  may  include  finding,  identifying  and  tracking 
surface  contacts  such  as  fishing  vessels  or  illegal  immigrant  vessels,  drug  interdiction.  The  two 
new  tasks  are: 

Identification  and  tracking  of  surface  vessels.  The  most  common  situations  where  this 
occurs  are  when  a  no  emissions  rule  is  in  force,  or  where  surface  radar  is  down.  The 
objective  is  to  identify  and  track  any  friendly,  neutral  or  hostile  contact  normally  tracked 
by  shipboard  or  other  radar  systems. 

Detection  and  tracking  of  a  torpedo  (enemy  or  friendly).  One  operator  would  have 

_ primary  responsibility  for  this  function. _ 
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As  far  as  can  be  determined  at  this  point,  neither  of  the  above  requires  unique  new  lower  level 
functions  to  be  added  to  the  function  analysis.  Instead,  for  these  two  tasks  there  are  differences 
in  the  way  some  of  the  generic  variables  identified  in  the  YARD  analysis  influence  sub-functions. 
For  example,  in  the  detection  and  tracking  of  a  torpedo  launch,  distances  may  be  much  shorter 
than  the  typical  range  over  which  passive  operations  are  conducted.  As  a  consequence  time 
frames  are  reduced  and  analysis  and  decision  making  is  done  under  considerable  time  pressure. 

At  the  time  of  the  YARD  analysis  the  context  of  typical  missions  was  deep  water.  It  now 
appears  that  littoral  operations  within  a  Task  Group  (TG)  are  becoming  increasingly  common. 
While  this  contextual  difference  does  not  change  the  major  mission  functions,  it  does  have 
implications  for  increased  operator  workload  due  to  more  rapid  oceanographic  and  environmental 
changes,  more  traffic  and  more  manoeuvring  by  own  ship.  Sonar  Operators  are  not  well  trained 
for  this  operational  context  now.  Also  the  relative  probability  of  certain  mission  functions  may 
have  changed.  For  example,  it  may  now  be  more  likely  that  surface  vessels  will  have  to  be 
found  and  tracked  close  inshore. 

A  summary  of  critical  points,  comments  and  possible  modifications  to  the  YARD  analysis  is 
shown  in  Table  1  below. 

3.2.2  Changes  to  the  YARD  analysis 

Note  that  the  initial  number  in  each  paragraph  is  the  function  reference. 

1.1.1b  Receive  intelligence  information 

In  setting  up  the  array,  operators  not  only  use  environmental  information  but  also  intelligence 
information.  This  function  in  the  YARD  analysis  appears  as  1.3.4  Use  intelligence  information 
only  in  the  context  of  search  for  threat  tonals.  It  is  suggested  that  this  function  be  added  to  the 
function  flow,  prior  to  setting  up  the  array  and  the  wording  changed  to  "Receive  and  use 
intelligence  information  " .  Since  this  is  the  first  time  this  function  appears  in  the  information 
flow,  it  should  be  renumbered  1.1.2  and  subsequent  function  renumbered  in  sequence. 

However,  for  convenience,  and  to  avoid  disrupting  the  existing  numbering,  it  has  been  labelled 
1.1.1b  (and  1.1.1  relabelled  as  1.1.1a). 

2.0  Classification  and  Localisation 

These  two  functions  are  combined  in  the  YARD  analysis  on  the  grounds  that  they  are  difficult  to 
differentiate  in  terms  of  the  unique  time  phases  when  each  is  being  separately  performed.  In  the 
YARD  analysis  while  there  is  some  decomposition  of  the  classification  function  into  sub-functions, 
the  only  sub-function  related  to  localisation  is  2.1  Resolve  Bearing  Ambiguity.  Since  another  sub¬ 
functions  relating  solely  to  the  localisation  process  has  been  identified,  it  is  suggested  localisation 
be  treated  as  a  separate  function  from  classification.  Further,  it  is  possible  that  new  tools  available 
through  TIAPS  will  differentially  support  either  classification  or  localisation  functions. 

Therefore  it  is  suggested  to  modify  the  analysis  to  include: 

1.4  Localise  target 

1.4.1  Resolve  bearing  ambiguity  (was  2.2.1)  -  including  4th  level  Junctions 

1.4.2  Generate  area  of  probability  for  target 
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Function  flows  associated  with  the  above  are  shown  in  Annex  B. 

3.2.3  Additional  functions 

The  following  suggestions  to  add  three  additional  functions  are  based  on  information  acquired 
during  the  familiarisation  visit.  The  degree  to  which  the  identified  second  level  functions  and 
associated  third  level  functions  are  involved  in  these  new  functions,  and  the  extent  to  which  they 
may  differ  in  operation  from  the  existing  functions,  remains  to  be  fully  validated  by  subject 
matter  experts  (SMEs). 

The  three  additional  functions,  and  associated  numbers,  are: 

Detect  torpedo  launch  (3.2) 

Build  surface  picture  (4.0) 

Prepare  Oceanographic  brief  for  CO  (5.0) 

Detect  torpedo  launch  (3.2) 

This  function  may  only  be  required  to  be  performed  during  an  engagement.  The  process  likely 
involves  functions:  1.3,  2.1,  2.2,  2.3,  2.4.  2.5,  2.6,  2.7. 

The  critical  issues  for  operator  performance  are: 

-  the  signature  is  difficult  to  localise  -  it  appears  only  in  broad  band 

-  operators  have  to  rely  on  contextual  information 

-  information  rates  are  very  high 

-  few  operators  have  had  opportunity  to  witness  a  live  signature 

-  once  detected,  the  critical  first  task  is  to  resolve  ambiguity;  this  is  usually  through  a 
best  guess  based  on  intelligence,  since  the  signal  information  itself  is  not  usually  useful  in 
providing  cues. 

Build  surface  picture  (4.0) 

This  function  is  performed  when  surface  radar  is  down  or  when  other  circumstances  require  that 
the  surface  tactical  picture  be  compiled  from  sonar  data. 

This  tasking  appears  to  involve  functions:  1.2,  1.1.  lb,  2.1,  2.2,  2.3,  2.4,  2.6  and  is  done  by 
operators.  The  general  goal  is  to  build  the  gross  picture  (note:  target  motion  analysis  (TMA) 
would  be  required  to  develop  a  more  refined  picture)  and  to  provide  identification  of  a  surface 
group.  To  assist  this  task,  the  general  tactical  picture  is  available  to  operators  and  is  displayed 
on  a  monitor  between  the  two  CANT ASS  consoles 

A  critical  aspect  of  this  task  is  that  operators  are  less  well  trained  in  recognition  of  surface 
vessels  and  also  the  database  of  known  signatures  is  less  complete. 

Prepare  Oceanographic  brief  for  Commanding  Officer  (CO)  (5.0) 

This  is  done  once  a  day  (with  a  24  hour  overview). 
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3.2.4  Summary  of  critical  points  and  comments 


Table  3:  summary  of  critical  points,  comments  and  possible  modifications  to  the  YARD 
analysis. 


Function 

Modification  (bold)  or  Comments 

1.  Search  and  Detection 

1.1  set  up  array 

ASWC  and  Towed  array  supervisor  (TasSup 
decide  where  to  place  array.  -  takes  2-5  mins  to 
setup  and  reset  verniers 

Vernier  setup  based  upon  Intel  and  experience. 

1.1.1  Receive  environmental  information 

This  task  is  repeated  throughout  the  mission  as 
new  information  comes  in  about  every  30  minutes. 

1.1.1a  Receive  and  use  intelligence  information 

1.1.2  Advise  on  scope  and  depth  of  array 

1.1.3  Set  array  receiver  parameters 

1 . 1 .4  Set  signal  processing  parameters 

Set  up  main  windows;  integration  period  is  usually 
set  to  8-32  seconds. 

1.1.5  Set  track  processing  parameters 

This  involves  setting  minimum  probability  of 
detection  for  Automated  Initiated  Tracks  (AIT). 

Note  operators  tend  to  turn  the  AIT  function  off, 
because  the  system  is  continuously  failing  and 
initiating  new  tracks,  in  many  cases  for  the  same 
source.  This  generates  too  much  “noise" 

1.1.6  Set  system  parameters 

Parameters  such  as:  magnetic  variation,  heading, 
source  (operator  or  array),  array  depth,  water 
temperature  obtained  from  stateboard. 

1 .2  Isolate  non-threat  tonals 

Generically  referred  to  as  “sanitising  the  array" 

1.2.1  Obtain  information  on  known  non¬ 
threats 

This  is  essentially  eliminating  the  “noise"  from  TG 
using  SB  and  3B  mode. 

This  is  a  major  task  in  a  seven  ship  TG  and  is  done 
repeatedly  on  most  missions,  as  frequently  as 
every  15  minutes.  In  littoral  settings  more  difficult, 
more  contacts,  and  more  noise. 

The  process  may  also  increase  display  noise  since 
identified  target  tracks  cannot  normally  be  dropped 
under  existing  operational  procedures. 

1 .2.2  Isolate  own  force  tonals 

Page  28  Humansystems  Incorporated 

Final  Report  HF  review  of  OMI  for  Sonar/Combat  Systems  under  Development  at  DREA 


„P51 6264.PDF  [Page:  46  of  202] 


1 .2.3  Obtain  information  on  own  force 
manoeuvres 

Done  in  parallel  with  1.2.4,  manoeuvres  range  from 
simple  changes  of  course,  avoidance,  helo 
operations,  zig-zag,  etc. 

1 .2.4  Isolate  other  non-threat  tonals 

High  workload.  Considerable  manual  data  logging. 
Task  shared  by  Sonar  Operator  (SonOp)  and  SCS. 

1 .3  Search  for  threat  tonals 

Frequently  done  in  parallel  with  1 .2  by  one  SonOp. 
Typically  one  SonOp  searches  forward,  the  other 
aft. 

Initial  search  based  on  Intel,  hunches  based  upon 
experience, 

May  be  done  in  response  to  requests  for  info  to 
correlate  with  sensors  on  other  platforms. 

Done  in  3B  mode  and  takes  4-5  minutes. 

An  on-line  database  of  known  signatures  would 
facilitate  this  task. 

1.3.1  Process  raw  acoustic  data 

Critical  task  sequence  is:  target  detection  and 
identification,  classification,  speed,  bearing, 
bearing  accuracy/uncertainty 

No  specific  tools  available  to  assist  ID. 

1 .3.2  Check  acoustic  displays  of 
processed  data 

1 .3.3  Examine  threat  tonal  list 

1 

CFC  1 13  -  provides  a  “cheat  sheet”  of  acoustic 
signatures  in  document  format.  Mostly  tabular 
data,  but  has  some  grams.  Also  have  available 
from  training  packages  real  acoustic  data  from 
known  sources 

1 .3.4  Use  intelligence  information 

Ops  build  up  local  database  during  course  of 
operation.  Another  source  is  a  CD  from  the 

Acoustic  Data  Analysis  Centre  (ADAC). 

2.  Classification  and  localisation 

Once  a  possible  contact  is  detected,  one  SonOp 
will  continue  the  search  fore  and  aft),  while  the 
other  looks  after  contact  identification  and  tracking. 

Suggest  separate  classification  from 
localisation  functions, 

2.1  Maintain  detection 

2.1.1  Diagnose  why  contact  has  been 
lost/faded 
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2.1.2  Change  signal  processing  and  array 
receiver  parameters 

2.1.3  Advise  on  change  of  course,  speed 
of  ship,  scope  and  depth  of  array 

2.2  Resolve  bearing  ambiguity 

Done  by  SonOp  may  take  5-20  mins. 

2.2.1  Check  broadband  display  for  true 
bearing  clues 

2.2.X  Determine  area  of  probability  for 
localising  target 

(to  be  added  as  a  sub-function  under  "localisation") 

This  usually  through  a  cross  check  with  another 
platform 

Range  estimate  depends  on  CZ,  BB,  DP  and 
speed  across  beams 

2.2.2  Communicate  with  ops  room  during 
manoeuvre 

2.2.3  Commence  updating  TMA  with 
bearing  frequency  and  time 
information 

Not  done  at  level  of  SCS  or  SonOps 

2.2.4  Update  target  detail 

2.3  Provide  initial  classification 

2.4  Maintain  target  details 

2.4. 1  update  markers  and  tracks 

2.4.2  update  target  details 

A  single  operator  will  normally  track  one  identified 
targets  at  a  time,  rarely  two. 

If  tracks  are  lost,  contact  details  are  deleted. 

System  can  maintain  99  contacts 

T racks  are  dropped  if  they  are  deemed  not  to  be  a 
contact  of  interest  (note  this  track  tag  only  not  the 
signature  lines).  Deleted  tracks  are  automatically 
dropped  as  update  to  CCS . 

2.4.3  update  ADLIPS 

Replace  ADLIPS  with  Command  Control  System 
(CCS).  (ADLIPS  was  a  predecessor  system  to  the 
CCS) 

2.4.4  initiate  and  delete  tracks 

2.4.5  co-ordinate  BB  information 
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2.5  separate  threat  target  from  own  force  tonals 

Needs  to  be  done  as  info  fades  in  and  out. 

SonOp  does  the  analysis. 

2.5.1  Communicate  need  to  separate 
signatures 

2.5.2  re-evaluate  signature  in  beam(s) 

2.6  datalogging 

This  task  is  intensive  and  critical. 

2.7  refine  classification 

Types:  operator  or  command  classification  ( 
ASWC-ORO-CO).  ASWC  responsible  for  getting 
cross  reference  info  and  feeding  down  to  SCS  and 
Ops. 

2.8  Provide  information  for  TMA 

CANTASS  v4  has  tools  for  Target  Motion  Analysis 
(TMA). 

Currently  done  verbal  comm  link  (not  data) 

investigate  area  of  operation  (AOP) 

MPA  and  Helo  do  own  target  ID  -  provide  info  via 
ASWC  to  ORO. 

Picture  compilation  is  done  at  the  level  of  the 

ASWC. 

Towed  array  sonar  reports  (TASREPS)  are 
updated  every  15  mins  or  more  frequently  for 
important  new  info.-  this  may  be  through 
stateboard,  but  usually  verbal. 

Have  ability  to  recall  acoustic  data  -  this  could  be 
used  to  assist  the  review  of  critical  data. 

Contact  report  goes  out  to  other  ships  via  SCS- 
ASWC  on  external  nets. 

Will  look  for  dynamic  changes  during  an 
engagement  and  may  provide  some  damage 
estimates 

2.8.1  create  ADLIPS 

Now  done  automatically  through  CCS 

2.8.2  communicate  with  TMA  to 
synchronise  timing 

2.9  provide  information  for  MPA/HELO  ops 
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3.0  Prosecute  target 

3.2  Detect  torpedo  launch 

the  signature  is  difficult  to  localise  -  it  appears  only 
in  broad  band 

-  operators  have  to  rely  on  contextual  information 

-  information  rates  are  very  high 

-  few  SonOps  have  had  opportunity  to  witness  a 
live  signature 

-  once  detected,  the  critical  first  task  is  to  resolve 
ambiguity;  this  is  usually  through  a  best  guess 
based  on  intelligence,  since  the  signal  information 
itself  is  not  usually  useful  in  providing  cues. 

4.0  Build  surface  picture 

5.0  Prepare  oceanographic  brief  for  CO 

This  is  done  once  a  day  (with  24  hour  overview) 

3.2.5  Ancillary  functions  for  which  future  analysis  may  be  required 

The  following  functions  were  briefly  mentioned  during  the  familiarisation  visit,  it  is  not  known  at 
the  present  time,  whether  analysis  of  these  will  fall  within  the  scope  of  the  present  project 
objectives. 

•  Bathy  drop 

•  Sonarbuoy  deployment 

•  TMA 

3.3  Summary 

Overall,  the  YARD  analysis  remains  substantially  accurate  and  complete  in  reflecting  the 
functions  involved  in  the  current  operational  usage  of  CANTASS.  A  small  number  of  changes 
and  modifications  are  suggested  to  reflect  current  practice  and  these  are  integrated  into  the 
revised  function  flow  in  Annex  B2. 
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4.  TIAPS  Function  Analysis 


4.1  Background 

The  TIAPS  system  is  a  research  and  development  technology  demonstrator  to  explore  the 
feasibility  of  combining  passive  and  active  sonar  systems  with  a  view  to  improving  underwater 
picture  compilation.  In  addition,  certain  tools  and  capabilities  are  being  explored  with  a  view  to 
reducing  the  operator  workload  involved  in  the  existing  search,  detection,  identification  and 
localisation  tasks.  At  the  present  time  it  is  not  known  what  aspects  of  the  system  may  be 
eventually  placed  in  an  operational  environment. 

A  full  description  of  the  TIAPS  system  can  be  found  in  CDC  (1999a, b). 

4.2  Objectives 

•  To  provide  a  base  reference  framework  for  existing  TIAPS  functions  under 
development  that  will  also  allow  future  functions  to  be  integrated 

•  To  identify  critical  operator  tasks  that  will  require  some  research  effort  to  provide 
appropriate  human  factors  (HF)  input  to  the  design  process. 

•  To  identify  areas  of  functionality  where  the  design  of  the  operator  machine  interface 
(OMI)  will  need  to  be  sensitive  to  specific  operator  requirement  or  limitations. 

•  To  identify  areas  of  the  TIAPS  OMI  that  will  require  particular  research  and 
development  effort. 

4.3  Mission  Analysis 

While  the  SOW  does  not  specifically  require  a  mission  analysis  to  be  conducted  as  the  normal 
preliminary  step  to  a  function  analysis,  it  is  important  to  view  the  TIAPS  functionality  against 
possible  mission  contexts.  Without  such  a  context,  any  description  of  the  system  functions  could 
be  inaccurate  and  inappropriate.  Thus,  some  speculation  is  in  order  concerning  the  potential 
operational  roles  for  TIAPS.  This  process  should  be  regarded  as  somewhat  conjectural  right  now, 
since  the  potential  applications  for  TIAPS  will  no  doubt  change  as  a  result  of  two  factors.  First, 
at  a  technical  level  the  functionality  will  continue  to  evolve,  as  experience  is  obtained  on  how 
functions  actually  work  in  practice  (e.g.  autotrackers)  and,  second,  at  a  military  level  new 
strategic  directions,  doctrines  and  mission  roles  may  emerge. 

Information  on  the  possible  roles  for  TIAPS  can  be  ascertained  from  the  scientists  centrally 
responsible  for  its  conception  and  development,  the  engineers  responsible  for  its  implementation 
and  the  military.  The  information  presented  below  therefore  represents  the  outcome  of  some 
discussions  with  defence  scientists,  software  developers  and  information  gathered  from  relevant 
system  technical  documents  as  well  as  military  concept  documents  representing  emerging 
directions  and  doctrine. 
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TIAPS  is  clearly  designed  to  address  the  Navy's  continuing  requirement  for  surveillance 
operations.  This  requirement  is  one  of  the  major  areas  for  future  force  planning  and  defence 
thrusts  (National  Defence:  VCDS  Force  Planning  Scenarios,  1999)  as  well  a  focus  for  future 
naval  R&D  activities  (The  Naval  C2  Blueprint,  2010).  The  surveillance  process  will  continue  to 
involve  the  acoustic  detection  of  both  surface  vessels  and  submarines.  Against  this  general 
requirement  there  are  two  important  factors  to  consider.  First,  the  detection  range  of  existing 
active  sonar  systems  is  challenged  by  modern,  quieter  submarines.  Second,  there  is  an 
increasing  trend  to  move  from  blue  water  operations  to  Littoral  environments.  (Theriault,  1999) 

In  addition,  at  an  operational  level  there  is  a  desire  to  improve  the  Common  Operational  Picture 
(COP)  across  levels  of  command  as  well  as  improving  the  ability  to  make  rapid  and  accurate 
command  decisions  under  increasingly  higher  levels  of  information  load  (Handbook  5,  1997). 

As  a  result,  from  a  mission  perspective  there  is  both  a  need  to  integrate  the  information  provided 
by  TIAPS  upwards  into  the  COP,  as  well  as  providing  information  concerning  the  current  tactical 
picture  (TP)  downwards  to  underwater  warfare  (UW)  activities. 

A  further  factor  in  considering  TIAPS  in  an  operational  role  is  that  there  will  be  a  future  need,  as 
part  of  general  sonar  information  management,  to  integrate  data  from  other  sources  such  as 
multi-statics  into  a  common  sonar  suite. 

4.4  Function  Analysis 

Function  analysis  is  described  as  analysing  a  system  in  terms  of  the  functions  that  must  be 
performed  and  defining  the  logical  units  of  behaviour  of  the  system  (NATO  RSG  14,1992). 
However,  this  presumes  that  the  system  or  mission  goals  have  been  defined  to  allow  a  specification 
of  such  required  functional  components.  In  the  case  of  TIAPS  which  is  an  R&D  product  there  is 
some  uncertainty  concerning  the  specific  system  goals,  which  will  probably  not  be  finally  resolved 
until  the  product  has  undergone  sea  trials  and  has  been  integrated  into  naval  operations.  Feedback 
from  what  is  operationally  appropriate  and  feasible  with  the  system  will  then  provide  at  some  point 
in  the  future  the  ability  to  refine  the  theoretical  and  design  system  objectives. 

A  further  consideration  with  respect  to  function  analysis  is  the  perspectives  that  may  be  brought  to 
examining  and  describing  the  system  of  interest.  The  operational  perspective  requires  an  analysis 
that  looks  at  the  system  in  terms  of  what  mission  goals  it  is  designed  to  achieve,  and  defines  the 
necessary  functions  that  comprise  the  process.  In  contrast,  from  the  systems  engineering 
perspective,  the  word  "function"  is  often  used  by  software  engineers  to  describe  some  attribute  of  a 
system  at  the  coding  level.  For  example,  tools  that  are  used  to  assist  the  sonar  operator  in  the 
analysis  of  sonar  lines  of  interest  may  be  thought  of  as  defined  functional  elements  of  the  software. 
The  existing  documentation  on  TIAPS  (CDC  1999),  provides  a  good  example  of  functional 
descriptions  of  the  system  components  from  such  an  engineering  perspective.  For  present 
purposes,  the  view  has  been  adopted  to  examine  the  system  in  terms  of  its  potential  role  in  an 
operational  environment;  thus,  the  system  software  functions  described  in  the  above  documentation 
have  been  integrated,  where  possible  and  appropriate,  into  this  perspective. 

While  function  analysis  may  follow  a  variety  of  approaches,  the  SOW  requires  a  product  that 
follows  the  format  adopted  in  the  YARD  (1989)  analysis  of  CANTASS,  namely  a  function  flow 
diagram.  This  approach  shows  the  sequential  arrangement  of  functions  as  well  as  functions 
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performed  in  parallel.  (Note:  the  typical  use  of  the  term  parallel  in  a  function  analysis  does  not 
imply  anything  about  the  operator  having  to  actually  perform  tasks  in  parallel.  Instead,  it 
represents  a  group  of  functions  whose  completion  or  output  is  required  before  a  subsequent 
function). 

A  typical  function  analysis  represents  a  progressive  decomposition  of  the  system  downwards  to 
the  point  where  individual  operator  tasks  are  able  to  be  defined.  For  present  purposes,  it  was 
agreed  with  the  technical  authority  that  the  decomposition  would  be  conducted  no  lower  than 
third  level  functions,  where  such  decomposition  was  possible.  It  was  hoped  that  this  would  be  a 
sufficient  depth  of  analysis  to  allow  the  identification  of  gross  and  critical  tasks  that  would  be 
central  to  the  achievement  of  functions. 

4.5  Process 

The  normal  process  of  using  a  scenario-based  approach  to  define  system  or  mission  goals  is 
infeasible  given  that  the  TIAPS  system  is  a  research  and  development  concept  under  evolution, 
rather  than  a  system  that  is  being  built  to  meet  specific  operational  criteria.  While  potential 
mission  environments  have  been  identified,  and  these  can  guide  the  process  of  function  analysis 
to  some  extent,  in  practice  the  system  can  only  be  analysed  in  terms  of  potential  capabilities  in 
generic  UW  operations.  Operational  elements  such  as  surveillance,  detection  of  contacts,  tracking 
contacts,  prosecution,  and  building  both  the  recognised  maritime  picture  (RMP)  and  common 
operational  picture  (COP)  will  no  doubt  continue  to  be  cornerstones  of  future  UW  operations. 

The  actual  process  adopted  for  describing  the  functional  elements  of  TIAPS  was  therefore 
somewhat  pragmatic  and  informal.  Background  documentation  was  read,  discussions  were  held 
with  subject  matter  experts  (SMEs)  provisional  decompositions  and  analyses  were  generated  and 
subsequently  refined  as  a  result  of  feedback  and  further  discussions. 

The  original  intent  was  to  decompose  functions  down  to  the  second  or  third  level,  where 
appropriate,  to  be  consistent  with  the  prior  function  analysis  for  CANTASS  (YARD,  1989). 
However,  it  was  decided  to  go  lower  levels  of  decomposition  for  some  of  the  more  critical  areas 
of  TIAPS,  in  order  to  understand  better  some  of  the  operator  tasks,  their  relationship  to  each 
other  and  to  provide  a  map  of  the  overall  complexity  that  results  when  both  active  and  sonar 
systems  are  combined  into  a  common  suite. 

4.6  Results 

The  results  are  outlined  in  three  major  sub-sections;  the  first  deals  with  the  TIAPS  mission  goals 
and  concept  of  operations,  the  second  covers  the  function  analysis  and  the  third,  critical  tasks. 

4.6.1  Mission  goals  and  concept  of  operations 

The  generic  mission  goal  that  TIAPS  is  designed  to  serve  can  be  described  as 

"Create  and  maintain  the  UW  tactical  picture" 
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This  picture  comprises  elements  of: 

Surface  vessels  and  sub-surface  vessels 
All  detected  sonar  sources 
Contact  tracks 

Location  and  movement  of  contacts  of  interest 

Selected  geographical  and  underwater  environment  information 

Unlike  CANTASS,  where  the  role  is  primarily  one  of  surveillance  of  relatively  "noisy"  contacts 
in  deep  water,  TIAPS  missions  are  likely  to  involve  additional  types  of  operating  environments, 
which  include: 

shallow  and/or  littoral  waters  with  associated  impact  on  performance  on  acoustic 
sensors 

tactical  scenarios  in  which  there  is  a  "proactive"  search  for  a  specific  contact  (i.e.  not 
generic  surveillance  as  is  the  case  with  CANTASS.  However,  there  is  no  consensus 
among  the  development  team  on  this  point  and  military  SMEs  have  yet  to  comment 
on  this  role) 

quieter  submarines  which  will  be  more  difficult  to  detect  by  passive  sonar, 
particularly  in  a  littoral  environment 

detection  of  torpedoes 

undersea  launch  of  anti-ship  missiles 

convoy  barrier  operations 

The  role  of  active  and  passive 

TIAPS  will  provide  access  to  both  active  and  passive  processed  acoustical  data.  The  TIAPS 
system  can  operate  in  one  of  three  modes:  passive  only,  mainly  passive  +  occasional  ping  and 
regular  active  schedule.  The  decision  is  made  at  the  task  group  (TG)  level  on  which  mode  is 
used  and  is  based  on  the  tactical  situation  and  ongoing  emissions  policy.  One  role  for  the  active 
component  of  TIAPS  may  be  for  target  localisation,  while  passive  data  could  still  be  required  for 
identification  and  classification.  Active  sonar  may  also  play  a  greater  role  in  shallow  water  and 
littoral  contexts. 

The  role  of  operators 

The  role  of  the  operator  may  change  from  the  present  focus  on  the  primary  task  of  the  search  for 
threat  tonals  (and  associated  tasks)  to  one  in  which  the  first  level  function  is  to  respond  to  "alerts" 
(i.e.  the  output  of  automatic  processors  for  detection).  This  may  be  accompanied  by  a  shift  in 
resources  from  the  present  compliment  of  a  sonar  supervisor  and  two  operators,  to  a  two-person 
operation  with  just  one  operator  and  supervisor.  It  is  speculated  that  the  supervisor's  role  will  be 
to  ensure  that  the  UW  tactical  picture  (based  upon  analysed  data  from  automated  processes)  is 
accurate  and  current.  To  achieve  this  the  supervisor  may  need  to  conduct  additional  analyses 
using  system  tools  on  either  active,  passive  data  or  both. 
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Operator  aiding 

The  provision  of  a  tool  suite  to  assist  the  operator  perform  a  variety  of  operational  tasks  is 
anticipated.  This  suite  may  include  display  parameter  tools  (e.g.  contact  rings,  environmental 
overlays,  integrated  data,  tools  to  assist  in  the  selection  of  models,  such  as  bathymetric  and  ping 
sequences) 

System  overview 

Hardware:  current  thinking  is  that  the  system  will  have  two  high  resolution  colour  monitors.  At 
present,  development  work  is  proceeding  with  a  Sony  2kx2k  resolution  CRT  monitor,  but  it  is 
envisaged  that  final  configuration  will  comprise  two  21"  1600x1200  LCD,  display  panels  with 
4:3  aspect  ratio.  These  will  be  arranged  either  in  an  over-and-under  configuration,  or  tiled 
contiguously  along  the  horizontal  dimension  (to  provide  a  'virtual'  monitor.  There  is 
consideration  of  a  plan  to  use  a  touch  panel  as  the  primary  input  mode,  supplemented  by  as 
trackball  and  keyboard  for  minor  input. 

TIAPS  is  capable  of  generating  acoustic  data  on  over  200  beams.  Since  it  would  be  impractical 
for  operators  to  perform  the  fundamental  function  of  signal  detection  by  scrolling  through  the 
beams  (as  is  the  case  at  present),  computer  assisted  detection  provides  a  core  functionality  in  the 
system. 

Therefore,  a  major  change  in  operator  roles  from  CANTASS  is  anticipated,  in  that  a  primary 
task  for  the  operator  will  be  to  monitor  the  outcome  of  automated  processes  that  he/she  has 
configured  and  initiated.  The  primary  task  of  the  supervisor  will  be  to  determine  the  ground 
truth,  or  what  is  believed  to  be  "real",  based  upon  further  analysis  of  the  information  provided  by 
automated  processes.  The  supervisor  will  have  the  responsibility  of  ensuring  that  the  underwater 
tactical  picture  is  accurate  so  that  it  can  be  incorporated  into  the  common  operational  picture  at 
the  command  level. 

The  primary  TIAPS  display  comprises  a  tactical  situation  map  (derived  from  the  Global  Command 
and  Control  System  (GCCS)  library,  as  well  as  standard  commercial  oceanographic  and 
geographical  databases);  Link  1 1  data,  multistatic  sources  and  the  RMP  can  be  overlaid  on  this. 

Known  surface  and  sub-surface  contacts  are  displayed  using  standard  NATO  symbology  for 
contact  type  and  course.  Operators  can  click  on  a  contact  for  more  detailed  information.  Such 
contacts  may  include  friendly,  enemy  and  neutral  vessels  and  commercial  traffic. 

Unknown  contacts  are  depicted  as  coloured  coded  dots-  red  =  fast  closing,  green  =  slow 
closing,  yellow  =  fast  leaving.  For  each  unknown  contact,  the  operator  can  invoke  a  contact  ring 
located  concentrically  on  the  current  own  ship's  position.  Textual  data  located  on  a  computed 
bearing  on  the  ring  perimeter  show  the  relevant  broad  or  narrow  band  frequency  information  for 
the  target.  The  ring  diameter  itself  bears  no  spatial  relationship  to  the  target,  but  serves  as  a 
convenient  parking  place  on  which  contact  information  can  be  readily  located.  Unknown 
contacts  can  be  interrogated  (via  a  mouse  click)  to  access  processed  passive  data,  and  hence  make 
available  all  of  the  existing  functionality  of  CANTASS.  Additional  tools  such  as  ratio  cursors  are 
available  to  assist  the  classification  process. 
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Several  tools  to  assist  the  operator  are  currently  under  development.  The  following  represents 
some  examples  that  have  been  demonstrated  to  date  during  the  familiarisation  for  this  contract 
and  is  not  intended  as  a  complete  listing  of  the  tool  set. 

Contact  association:  this  tool  is  designed  to  allow  an  operator  to  associate  data  in  one  window 
with  that  in  another,  for  example  between  the  tactical  display  and  a  broad  band  display.3  For 
example,  on  the  tactical  display  the  operator  may  sweep  a  radial  cursor  centred  on  the  ship  and 
locate  a  track  or  contact  of  interest,  in  an  associated  broad  band  display,  this  movement  is 
tracked  and  shown  as  moving  vertical  cursors  across  beams.  In  this  way,  acoustic  data  can  be 
simultaneously  associated  with  processed  contact  data  and  the  operator  may  be  able  to  resolve 
contact  details  or  determine  more  about  the  contact  identity. 

Target  motion  analysis:  This  tool  will  integrate  and  refine  some  of  the  existing  tools  (e.g.  Passive 
Localisation  Assistant  -PLA)  to  provide  a  more  rapid  and  accurate  method  for  assessing  the  track 
and  speed  of  a  contact  of  interest.  The  display  shows  the  Ecklund  legs  of  a  ship's  track  with 
associated  bearing  sectors  on  which  contact  data  has  been  detected.  The  operator  can  specify  a 
possible  target  track  within  this  area  of  contact  by  plotting  a  line  and  obtain  immediate  feedback 
of  the  residual  data  fit  around  the  line.  In  this  way,  the  operator  can  manipulate  contact 
characteristics  in  real  time  and  receive  visual  feedback  on  the  track  that  best  fits  the  data. 

4.6.2  Function  analysis 

The  following  section  summarises  the  TIAPS  functions  that  have  been  identified.  Function 
descriptions  typically  comprise  the  following  components  (derived  from  the  YARD  analysis): 
function  descriptions  and  function  flow  diagrams,  full  details  of  which  are  provided  in  Annex  C. 

Function  descriptions  have  the  following  format  (based  upon  the  YARD  documentation). 

1 .  Name  of  Function 

2.  Missions  Under  Which  Function  Occurs 

3.  System  Units  Which  Support  Function 

4.  Superordinate  Functions 

5.  Sequential  Categorisation  of  Functions 

6.  Estimate  of  Criticality  of  Function 

7.  Critical  Variables  (e.g.  own  ship  speed,  own  ship  manoeuvres,  oceanographic 
conditions) 

8.  Required  Quality  of  Output  for  Function 


3  The  word  "window"  is  used  to  represent  a  separate  display  entity  that  shows  data  containing 
some  aspect  of  the  system  functionality,  examples  would  be  a  broad  band  display,  tactical 
display,  beam  display  etc.  The  word  display  is  not  meant  to  imply  that  there  is  a  unique  monitor 
associated  with  each  display  format.  In  other  words,  many  display  windows  are  capable  of  being 
rendered  on  each  of  the  monitors  that  will  comprise  the  TIAPS  workstation. 
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9.  Estimate  of  Probability  of  Failure  to  Complete  A  Function 

10.  Consequences  of  Failure  to  Complete  A  Function 

1 1 .  Estimate  of  Time  to  Completion 

12.  Sub-functions  Or  Tasks 

13.  Sequencing  of  Sub-functions  or  Tasks 

14.  Allocation  of  Function  to  Man,  Software  or  Hardware 

15.  Interdependency  Of  Functions 

Given  the  early  stages  of  development  of  the  TIAPS  system,  it  is  not  possible  to  address  with  a 
reasonable  degree  of  certainty  the  data  that  should  be  entered  into  many  of  these  descriptions,  for 
example,  probability  of  failure  and  time  to  complete  functions.  Further,  based  on  the  YARD 
report,  the  category  Critical  Variables  tend  to  be  somewhat  constant  across  most  functions  (even 
if  they  could  be  identified  at  this  stage).  Therefore,  the  function  descriptions  for  each  function 
will  typically  only  include  itemsl,  4,  5,  6,  10,  12,  13,  14,  15.  The  remaining  categories  will 
remain  as  placeholders  for  now  to  allow  more  detail  to  be  incorporated  into  the  functional 
analysis  as  the  system  evolves. 

An  additional  category  "Comments"  has  been  added  to  allow  the  entry  of  specific  issues  of 
importance  that  will  need  to  be  considered  in  the  future. 

The  function  of  "building  and  maintaining  the  RMP"  has  not  been  included  in  the  analysis, 
although  it  seems  clear  that  TIAPS  could  provide  many  of  the  underlying  tools  that  are 
necessary.  Building  the  RMP  is  a  somewhat  different  function,  although  related  to  the  core 
TIAPS  function  of  building  and  maintaining  the  UW  tactical  picture.  For  the  RMP,  all  contacts 
and  relevant  data  within  the  area  of  interest  must  be  plotted  and  identified,  to  whatever  degree  is 
possible.  The  RMP  forms  a  contextual  backdrop  for  the  conduct  of  ongoing  operations  and  for 
the  planning  of  future  actions.  The  tactical  picture  may  be  regarded  as  a  local  subset  of 
information  within  the  RMP  in  which  information  and  data  of  immediate  relevance  to  tactical 
decision  making  is  plotted.  Thus,  for  any  particular  operational  decision,  information  may 
needed  to  be  added  or  filtered  from  the  RMP.  Information  to  be  added  might  include  estimates 
of  threat  ranges,  points  of  closest  contact  and  extrapolations  of  future  positions  of  contacts  of 
interest.  Information  removed  might  include  anything  that  is  not  relevant  to  the  specific  tactical 
decision  and  which  clutters  the  screen.  The  decision  as  to  whether  include  building  the  RMP  into 
the  functional  analysis  for  TIAPS  may  best  be  postponed  until  further  functionality  is  developed 
and  the  role  of  TIAPS  has  been  analysed  in  terms  of  how  it  will  serve  the  UW  team  and  how  that 
team  might  be  constructed  in  future.  If  fewer  personnel  are  anticipated  then  functions  such  as 
building  the  RMP  may  well  fall  within  the  responsibilities  of  the  TIAPS  team;  certainly,  TIAPS 
will  have  the  generic  capability  of  supporting  this  role. 
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1  ANALYSE  MISSION 

1.1.  Receive  Information 

1.1.1.  Receive  environmental  information 

1.1.2.  Receive  information  on  mission 

1.1.3.  Receive  organic  and  non-organic  intelligence 

1.1.4.  Receive  direction  on  threats  from  command  team 

1 .2.  Configure  workstation 

1.2.1.  Configure  workstation  for  mission  type  (load  appropriate  databases) 

1 .2.2.  Set  local  preferences 

1  3.  Configure  active  sonar 

1.3.1.  Set  waveform 

1.3.2.  Setwavetrain 

1  3  3.  Set  ping  bundle 

1 .3.4.  Set  false  alarm  rate  for  autodetectors 

1 .4.  Configure  passive  sonar 

1.4.1.  Set  false  alarm  rate  for  autodetectors 

1.5.  Set  up  required  operating  mode  (fully  passive,  mostly  passive-infrequent  pings, 
regular  active  schedule) 

2.  CONFIGURE  SYSTEM  MODEL 

2.1  Create  and  maintain  environmental  model  (continuous  process) 

2.1.1.  Add  current  information  (sound  speed  profile,  location,  sea  state) 

2.1.2.  Run  and  refine  model  (based  largely  on  operator  experience) 

2.2.  Create  and  maintain  sonar  model 

2.2  1 .  Update  threat  information 

2.2  2.  Update  environment  information 

2.2.3.  Run  model 

2.2.4.  Array  motion 

2.3.  Evaluate  Model 

2.4.  Communicate  values  for  sonar  analysis 

3.  ASSESS  SYSTEM 

3.1.  Assess  environment 

3.2.  Assess  Sonar 

3.2.1 .  Analyse  array  motion 
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4.  CREATE  AND  MANAGE  TACTICAL  PICTURE 

4.1.  Receive  mission  parameters 

4.2.  Manage  TP  overlays 

4.3.  Select  and  manage  Dll/COE  data 

4.4.  Manage  contacts 

4.4.1.  Reduce  contact  clutter 

4.4.2.  Identify  non-threat  contacts  (possibly  of  auto  process  on  passive  side) 

4.4.3.  Identify  and  respond  to  unknown  contacts 

4.4.4.  Determine  contact  priority 

4.4.5.  Determine  contact  correlation/association  (same  or  different  source) 

4.5.  Analyse  contact 

4.5.1 .  Analyse  passive  sonar  data 

4. 5. 1.1.  Configure  system 

4.5. 1 .2.  Search  for  contacts  (detect) 

4.5. 1 .2. 1 .  Configure  signal  followers 

4.5.1 .2.2.  Check  what  computer  has  merged 

4.5.1 .2.3.  Check  what  auto  process  has  missed 

4.5.1 .2.4.  Verify  contacts  that  are  auto-detected 

4.5. 1.2.5.  Select  sonar  display  configuration  mode  (e.g.  bb/demo) 

4.5.1 .2.6.  Initiate  signal  followers  for  weaker  signals  not  auto-detected 

4.5.1 .2.7.  Analyse  acoustic  data 

4.5. 1 .2.8.  Analyse  non-acoustic  data 

4. 5. 1.3.  Classify 
4.5.14.  Localise 

4.5.1 .4.1 .  Manage  TMA  processor 

4.5. 1 .4. 1 . 1 .  Generate  localisation  solution 

4.5. 1.4. 1.2.  Evaluate  localisation  solution 

4.5.2.  Analyse  active  sonar  data 

4.5. 2.1 .  Check  bathy  information 

4.5. 2.2.  Configure  transmission 

4.5.2.2.1.  Set  Ping  sequence 

4.5.2.2.2.  Set  Waveform 

4. 5.2. 2. 3.  Set  sector 

4. 5. 2. 3.  Configure  receiver 

4.5.2. 3.1.  Configure  CW 

4.5.2. 3.2.  Configure  FM 
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4.5. 2.3.3.  Configure  ER 

4. 5.2.4.  Monitor  performance/progress  of  ping  schedule 

4.5.2.4.1.  Adjust  or  change  model  as  required 

4. 5.2. 5.  Search  for  contacts 

4. 5.2. 6.  Analyse  data 

4. 5.2. 7.  Classify  contact 

4.5.2. 7.1.  Extract  features 

4.5.2. 7.2.  Reduce  clutter 

4.5. 2. 7. 3.  Analyse  non-acoustic  data 

4.5.2. 8.  Localise  contact 

4. 5. 2. 8.1.  Determine  latitude  and  longitude 
4. 5. 2. 8  2.  Determine  course/speed 

4.6.  Manage  Tracks 

4.6. 1 .  Maintain  track  positions 

4.6.2.  Correlation/associate  tracks 

4.6.3.  Maintain  track  database 

4.6.4.  Report  tracks 

4  7.  Analyse  tactical  picture 

4.7.1.  Determine  contact  threat  level 

4.7.2.  Ensure  all  tracks  accounted  for 

4.7.3.  Delete  contacts  as  required 

4.8.  Refine  configuration  of  automated  processes 

4.8.1.  Evaluate  performance  of  automated  processes 

4.8.2.  Adjust  parameters 

5.  RECORD  AND  ANALYSE  DATA 
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4.6.3  Critical  Tasks 


At  the  present  level  of  system  development  some  degree  of  speculation  is  required  in  order  to 
establish  critical  tasks  that  will  need  to  be  performed.  The  identification  of  critical  tasks  will  be 
an  ongoing  process,  first,  as  parts  of  the  system  become  functional  and  available  for  operators  to 
work  with  in  a  demonstration  mode,  and,  subsequently  as  the  entire  system  is  fielded  and 
operational  experience  gained.  At  present,  the  specification  of  core  and  critical  tasks  is  based 
upon  some  broad  conceptions  of  how  the  system  will  be  operated  and  how  it  is  similar  or 
different  from  current  operational  practices  in  either  the  active  or  passive  sonar  domains. 

As  a  first  step  we  can  consider  the  critical  tasks  involved  in  passive  sonar  analysis  and  see  how 
they  may  be  different  in  TIAPS.  We  can  also  examine  tasks  that  will  be  anticipated  in  TIAPS 
but  have  no  counterpart  in  CANT  ASS. 

The  primary  tasks  in  passive  sonar  analysis  (based  on  CANTASS)  are: 
isolation  of  known  tonals 
search  for  threat  tonals 
detection  of  tonals 
contact  identification 
contact  localisation  and  tracking 
contact  classification 
Provisional  new  tasks  in  TIAPS  are: 

configuring  the  system 

evaluating  the  accuracy  of  the  output  of  automated  processes 

monitoring  the  output  of  automated  processes 

analysing  the  "truth"  concerning  auto-detected  contacts 

refining  automated  processes 

building  and  monitoring  the  tactical  picture 

building  and  maintaining  the  UW  RMP 

The  first  three  tasks  in  the  first  list,  which  are  highly  operator  intensive  in  CANTASS,  may  all 
fall  within  the  capability  of  automated  system  functions  in  TIAPS.  Given  improvements  in 
detection  sensitivity  of  the  system  and  an  improved  spatial  resolution  of  beams,  the  amount  of 
processed  information  available  will  be  considerably  higher  than  is  currently  the  case  in 
CANTASS.  It  would  be  unrealistic  to  expect  that  a  single  operator,  using  existing  CANTASS 
procedures  of  sequentially  scrolling  through  beams  to  find  acoustic  information  of  interest,  could 
process  the  information  in  a  sufficiently  timely  manner  for  operational  purposes.  TIAPS 
transforms  this  process  through  the  implementation  of  automated  signal  detection  and  analysis. 
Hence,  the  operator's  initial,  critical  task  will  be  to  configure  the  system  to  allow  such 
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automated  processes  to  run  appropriately  for  the  specific  circumstances  of  the  mission  context 
and  the  local  environment. 

It  is  also  expected  that  the  tasks  of  localisation  and  tracking  will  also  be  transformed  under 
TIAPS.  At  present  these  tasks  are  performed  off-line  from  CANTASS  through  largely  manual 
processes,  with  some  computer  assisted  tools  for  target  motion  analysis  (TMA).  These  tasks  are 
also  normally  performed  by  personnel  other  than  the  CANTASS  operators.  Under  TIAPS,  TMA 
will  be  fully  integrated  into  the  system,  which  will  provide  interactive  tools  for  more  rapidly 
estimating  target  course  and  speed. 

The  process  of  contact  classification  will  essentially  involve  the  same  sub-tasks  that  are  part  of 
existing  active  or  passive  sonar  analysis.  In  TIAPS,  when  operating  in  dual  mode,  operators  will 
have  additional  information  available  to  assist  the  classification  process.  While  this  may  improve 
the  accuracy  of  the  process,  it  is  not  known  at  this  time  whether  there  will  be  additional  analysis 
time  required  to  integrate  information  from  the  active  and  passive  systems.  It  is  also  possible 
that  some  of  the  tools  that  allow  association  between  acoustic  data  and  plotted  tracks  may  assist 
the  classification  process. 

TIAPS  tasks 

System  configuration. 

There  are  two  parts  to  this  process.  The  first  step  is  an  initial  configuration  of  the  workstation 
for  the  role  of  the  operator  or  supervisor  together  with  the  setting  of  some  broad  operational 
parameters  determined  by  the  tactical  context.  This  would  include  determining  the  relative  roles 
of  active  and  passive  and  configuring  each  system  for  the  local  water  environment  and  other 
conditions  affecting  system  transmitters  and  receivers.  The  second  step  in  the  process  is  the  task 
of  configuring  automated  detectors.  This  will  require  the  operator  to  determine  values  for  a 
number  of  parameters  that  will  influence  the  performance  of  the  detector.  It  is  expected  that  this 
process  will  be  facilitated  through  menu  selection  from  a  number  of  pre-configured  parameter 
data  sets  in  a  database.  It  will  be  critical  for  the  operator  to  perform  this  task  with  accuracy  and 
in  a  timely  manner.  Hence,  there  will  be  a  need  to  develop  an  appropriate  OMI  that  facilitates 
this  process.  Since  the  specific  sub-tasks  involved  in  setting  up  the  automated  trackers  have  yet 
to  be  identified,  the  particular  OMI  requirements  cannot  be  specified.  One  fundamental  task  that 
will  be  required  is  the  determination  of  the  appropriate  criterion  threshold  for  detection  by 
evaluating  the  performance  of  automated  processes. 

Evaluating  the  performance  of  automated  processes. 

Since  the  system  is  not  a  perfect  detector,  and  signals  and  noise  come  from  overlapping  acoustic 
distributions,  a  trade-off  will  always  have  to  be  made  between  making  the  system  yield  the 
minimum  number  of  false  alarms,  while  at  the  same  time  ensuring  that  potential  targets  are  not 
missed.  Since  operators  will  have  no  a  prior  knowledge  of  how  the  local  conditions  may 
influence  such  a  criterion,  there  will  be  an  ongoing  secondary  critical  task  for  operators  to  ensure 
that  the  detection  criterion  is  optimised.  The  achievement  of  the  required  proficiency  in 
performing  this  task  will  need  to  be  a  new  focus  for  training  of  operators,  but  no  matter  the  level 
of  proficiency  achieved,  operators  will  need  to  be  constantly  evaluating  the  performance  of 
automated  detectors  on  an  ongoing  basis.  To  achieve  this,  there  may  be  a  need  to  develop  a 
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capability  for  operators  to  replay  the  recent  acoustic  data  history  and  examine  the  effects  on 
signal  detection  outcome  (and  false  alarms)  by  manipulating  the  criterion  setting  in  more  or  less 
real  time.  In  this  way  operators  would  be  able  to  readily  determine  what  criterion  would  be  most 
effective  for  the  current  operational  conditions.  Special  consideration  will  be  need  to  be  given  to 
developing  an  OMI  that  facilitates  this  task. 

Monitoring  the  activity  and  output  of  automated  processes 

Unlike  CANT  ASS,  where  the  detection  and  track  initiation  processes  are  largely  processes  that 
are  assigned  to  the  operator,  in  TIAPS  the  operator's  role  is  to  monitor  the  output  of  such 
processes.  As  an  example,  one  approach  under  consideration  is  to  show  contacts  as  small  plots 
on  the  tactical  display,  coded  according  to  their  threat  profile,  using  the  coding  scheme  outlined 
earlier.  Hence  the  operator's  tasks  will  involve  the  detection  of  new  contact  plots  on  the  screen, 
the  determination  of  their  priority  for  further  scrutiny  and  the  analysis  of  the  underlying  acoustic 
data  to  establish  "truth"  concerning  the  auto-detected  contact. 

Analysing  the  "truth"  concerning  auto-detected  contacts 

Given  that  there  will  always  be  some  uncertainty  concerning  the  meaning  of  the  detected  contact, 
a  major  task  for  the  operator  will  be  to  analyse  the  auto-detected  contact  to  the  point  where  it  can 
either  be  rejected  as  noise,  or  accepted  as  a  contact  of  interest  that  will  require  further  analysis  in 
terms  of  identification,  tracking  and  classification.  As  an  initial  step,  the  operator  may  use 
information  on  the  contact  ring  to  establish  whether  there  is  a  known  track  along  the  bearing  of 
the  target  and  whether  the  contact  may  be  associated  with  this  known  track.  As  an  additional 
step  it  may  be  necessary  for  the  operator  (or  supervisor)  to  analyse  the  underlying  acoustic  data 
that  are  associated  with  the  contact.  This  process  may  be  somewhat  similar  to  existing  methods 
of  active  and  passive  acoustic  analysis,  supplemented  by  new  TIAPS  tools.  For  example,  the 
"association  window"  will  allow  the  operator  to  associate  graphically  both  processed  acoustic 
data  and  sounds  from  a  potential  source  with  tracks  displayed  upon  the  tactical  display. 

Refining  automated  processes 

As  a  result  of  the  three  prior  tasks,  the  operator  may  come  to  the  conclusion  that  automated 
detectors  and  processes  are  not  providing  the  required  information.  Consequently,  the  operator 
may  have  to  fine-tune  the  configuration  parameters  of  these  automated  processes.  In  deep  water 
operations  and  low  traffic  volumes,  this  task  may  need  o  be  done  somewhat  infrequently. 
However,  in  littoral  operations  and  higher  traffic  volumes,  there  may  be  a  need  for  frequent 
adjustments  of  parameters.  Hence,  an  OMI  design  that  allows  such  adjustments  in  an  expeditious 
and  accurate  manner  will  be  required. 

Building  and  monitoring  the  tactical  picture  (TP) 

Whether  this  task  is  performed  at  the  level  of  the  TIAPS  team  or  higher  in  command  structure  is 
unknown  at  present.  Given  that  TIAPS  will  provide  an  overall  TP  display  format,  it  is  possible 
that  the  supervisor  position  may  take  on  this  responsibility.  The  goal  of  this  process  is  to  link  the 
information  provided  by  sonar  analysis  to  the  immediate  operational  context  of  the  mission.  In 
other  words,  sonar  information  needs  to  be  interpreted  in  terms  of  its  tactical  significance.  Given 
the  potential  downloading  of  information  from  the  Defence  Information  Infrastructure  Common 
Operating  Environment  (DII/COE),  other  databases,  link  data  and  other  sources,  the  TIAPS 
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supervisor  will  have  the  necessary  functionality  to  create  an  intelligent  tactical  picture  that  may 
serve  the  needs  of  higher  command  levels.  The  task  of  building  the  tactical  picture  will  involve 
sub-tasks  of  data  filtering  (to  eliminate  tactically  irrelevant  data),  information  integration  and 
possibly  projection  of  future  state.  Related  to  this  process  is  the  task  of  building  and  maintaining 
the  UW  RMP. 

Building  and  maintaining  the  UW  RMP 

Again  it  is  not  known  if  this  task  would  be  performed  by  the  TIAPS  team,  however  the  system 
provides  the  necessary  functionality  for  the  task  to  be  performed  effectively  at  this  level.  At 
present,  the  building  of  the  UW  RMP  is  essentially  a  manual  and  intensive  process  that  involves 
the  integration  of  passive  and  possibly  active  sonar  information,  data  from  sonabuoys, 
intelligence  reports  and  link  data.  The  goal  is  to  identify  and  classify  all  UW  information  in  the 
area  of  interest.  The  tools  and  functionality  available  in  TIAPS  will  make  this  a  process  that  is 
more  effectively  and  expeditiously  accomplished  than  with  present  approaches.  TIAPS  not  only 
provides  a  comprehensive  system  for  analysis,  but  also  for  data  presentation  within  a  tactical 
format  that  can  be  readily  shared  among  the  command  team. 

4.7  Heuristic  Human  Factors  Review  of  the  TIAPS  OMI 

The  following  discussion  is  based  upon  a  review  of  two  aspects  of  the  display  functionality, 
namely  the  overall  tactical  sonar  display  and  a  "contact  association  display".  While,  none  of  the 
underlying  active  or  passive  data  displays  have  been  available  for  review,  it  is  understood  that 
these  have  a  similar  format  to  the  existing  510  and  CANT  ASS  systems.  As  such,  it  would  be 
somewhat  redundant  and  uninformative  to  review  them  in  the  present  context.  Since  these 
functions  represent  work  in  progress  rather  than  the  ultimate  design  concept,  it  would  be  unwise 
at  this  stage  to  provide  definitive  comments  on  the  full  spectrum  of  TIAPS  design  issues  or  to 
emphasise  too  greatly  any  existing  limitations  in  the  concepts  under  development. 

The  potential  range  of  human  factors  issues  in  TIAPS  is  quite  broad,  ranging  from  detailed  issues 
of  display  design  up  to  cognitive  representations  of  complex  tasks.  The  listing  below  does  not 
represent  an  ordered  set  of  priorities  for  improvements  but  can  be  thought  of  as  an  initial 
evaluation  of  the  currently  available  functions,  as  well  as  some  speculation  concerning  issues 
relating  to  the  development  of  a  variety  of  functions,  in  particular  relating  to  the  use  of  automated 
system  features. 

4.7.1  Display  issues 

4.7. 1.1  Contact  symbology:  size  and  colour. 

There  is  clearly  a  trade-off  between  the  size  of  the  symbology  and  its  potential  visibility.  There 
is  a  need  to  keep  contact  symbology  small  because  of  the  requirement  to  have  minimal  spatial 
uncertainty,  to  allow  history  trails  to  be  displayed  and  to  allow  multiple,  non-overlapping  targets 
to  be  rendered.  The  use  of  a  small,  single  pixel  target  to  accomplish  this  raises  the  possibility 
(and  until  further  investigation,  this  is  just  a  possibility)  of  some  human  perceptual  issues,  as 
noted  below. 
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4.7.1. 2  Discriminability  of  coloured  targets. 

The  choice  of  red  colour  code  to  indicate  the  high  salience  of  fast  closing  targets  is  a  natural  one, 
however  some  potential  problems  can  be  identified.  The  red  channel  on  most  coloured  CRT 
displays  has  limited  energy  output  (compared  with  green)  and  hence  the  maximum  luminance  of  a 
red  target  is  relatively  low.  While  the  associated  luminance  output  is  sufficient  under  most 
circumstances  to  generate  a  stimulus  that  meets  luminance  contrast  guidelines  for  detection,  there 
are  circumstances  where  the  visibility  of  the  contact  symbols  may  become  compromised.  Such 
circumstances  are: 

•  where  the  ambient  room  light  is  red  and  or  at  a  low  level 

•  LCD  display  technology  (for  which  visibility  of  single  pixel  targets  and  reduced 
display  contrast  with  off-axis  viewing  are  known  problems) 

•  the  overall  display  contrast  and/or  brightness  has  been  reduced  by  the  operator  (for 
example,  to  prevent  other  display  elements  from  being  too  visually  dominant) 

•  a  cluster  of  adjacent  symbols  is  in  close  proximity  to  each  other 

•  where  the  contact  symbol  may  be  overlaid  by,  or  be  close  to,  other  display  elements 
(e.g.  contact  rings,  numerical  data) 

•  where  the  display  luminance  output  has  degraded  over  time,  in  which  case  luminance 
output  for  the  red  and  blue  channels  becomes  more  compromised  than  green,  because 
of  the  lower  overall  energy  output. 

•  Where  other  display  elements  (for  example,  green  or  yellow  symbols)  have  higher 
energy  and  hence  greater  luminance  contrast.  These  may  mean  that  they  are  easier  to 
detect,  are  more  visually  prominent  and  hence  have  the  potential  for  impairing  the 
recognition  of  the  red  contact  symbology. 

Overall,  it  may  be  tentatively  concluded  that  the  high  salience  and  alerting  properties  of  the 
contact  may  become  compromised  by  the  above  factors. 

Some  immediate  design  solutions  to  consider  are: 

•  Consider  other  colour  coding,  symbology,  or  format  options  (e.g.  flashing)  for  the 
high  salient  contacts.  NATO  STANAG  4420  may  provide  some  guidance  on 
symbology  for  contacts  that  have  not  been  confirmed  or  formally  classified. 

•  Use  a  larger  symbol  for  the  contacts 

•  Ensure  that  the  operator  is  provided  with  a  brightness  control  that  allows  the 
luminance  of  the  contact  dots  to  be  adjusted  independent  of  other  display  elements. 

•  Provide  independent  brightness  controls  for  all  major  display  elements  (e.g.  overlays, 
alphanumerical  data  blocks,  contact  rings,  oceanographic  and  geographical  data,  ) 

•  Provide  for  a  blink  capability  to  red  contact  symbols  (under  appropriate 
circumstances)  to  increase  discriminability. 
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•  Allow  selective  display  elements  to  be  turned  off  under  operator  control,  where  their 
close  spatial  presence  may  impact  upon  the  discriminability  of  contact  symbols 

Some  of  these  issues  will  need  to  be  investigated  empirically  during  system  development.  Of 
priority  will  be  the  need  to  look  at  the  provision  of  independent  brightness  control  to  some 
display  elements,  since  past  experience  with  similar  technologies  and  software  suggest  that  COTS 
products  have  limited  capability  to  provide  such  functionality. 

4.7. 1.3  Text  and  fonts 

Since  the  tactical  display  format  may  result  in  the  display  of  a  large  number  of  contacts  and 
tracks  and  associated  symbol  and  alphanumeric  data,  the  potential  exists  for  display  clutter.  Such 
clutter  may  result  in  impairments  to  the  operator’s  ability  to  detect,  search  and  read  information. 
Hence,  some  discipline  will  be  necessary  in  the  choice  of  text  and  symbology  to  minimise  this 
potential.  The  following  areas  will  need  to  be  addressed:  selection  of  font  type  and  size,  contrast 
and  colour  characteristics,  size  and  colour  coding  of  symbols.  The  evaluation  of  these  areas  will 
need  to  be  conducted  within  a  variety  of  display  formats  ranging  from  a  relatively  uncluttered 
display  (with  minimal  background  fill  and  overlays)  to  ones  which  contain  large  amounts  of  data, 
overlays  involving  area  fills  and  overlays  with  other  types  of  information  (e.g.  contact  rings). 

4.7.2  Contact  rings 

The  concept  of  contact  rings,  as  described  earlier,  is  to  provide  the  operator  on  the  tactical 
display  with  any  contextual  data  that  may  be  available  on  a  particular  bearing.  The  proposed 
manner  of  implementation  using  rings  does  however  raise  some  human  factors  issues.  The  most 
important  concern  is  that  bearing  rings  will  be  confused  with  the  highly  overlearned  concept  of 
range  rings;  these  are  widely  used  in  tactical  displays  in  several  domains  to  provide  a  visual  cue 
of  range  distance  information  normally  centred  on  own  platform.  In  conditions  of  stress,  high 
workload  and  rapid  decision  making,  operators  will  tend  to  really  heavily  on  overleamed 
concepts,  thus  a  contact  ring  could  be  confused  with  a  range  distance  ring.  It  is  recommended 
that  the  design  should  be  re-evaluated  to  eliminate  the  potential  confusion.  One  approach  would 
be  to  use  different  colour  and  line  coding  for  the  contact  rings  and  range  rings:  for  example, 
range  rings  might  be  solid  lines  of  one  hue  and  contact  rings  a  broken  or  dotted  line  with  a  less 
conspicuous  hue  and  luminance.  Conspicuity  should  be  reduced  for  the  contact  rings,  no  matter 
the  type  of  coding,  since  the  salient  information  is  not  the  ring  itself  but  the  data  attached  to  it. 
Another  approach  that  might  avoid  any  shape  confusion  whatsoever,  is  to  use  radial  lines  from 
own  platform  to  indicate  the  bearing  containing  the  data  of  interest.  Again,  such  lines  should 
have  lower  luminance,  be  broken  or  dotted,  and/or  subtly  colour  coded  to  avoid  confusion  and 
interaction  with  other  more  tactically  salient  display  elements. 

Whatever  the  actual  implementation,  care  will  be  needed  to  avoid  the  possibility  of  screen  clutter 
with  implications  for  degraded  operator  performance  in  tasks  such  as  search  and  detection. 
Attention  should  be  given  to  developing  an  overall  colour  and  luminance  coding  approach  that 
will  minimise  the  potential  for  clutter. 
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4.7.3  Overall  workstation  configuration 

Given  the  planned  change  in  operator  manning  of  the  new  two-console  TIAPS  suite,  some 
general  workstation  configuration  and  design  issues  will  need  to  be  examined.  The  analysis  will 
not  only  need  to  look  at  the  need  for  operators  to  interact  between  the  TIAPS  suite  and  other  new 
or  existing  systems,  but  also  the  generic  need  for  ensuring  adequate  design  to  support  sharing 
information  among  other  OR  team  members  who  will  interact  in  and  around  the  TIAPS  system. 
While  these  exact  functions  remain  to  be  identified,  we  know  from  prior  analyses  that  team 
members  group  around  displays  to  discuss  and  share  content,  interact  with  other  displays  to 
integrate  relevant  information  and  pass  quickly  written  communications  and  notes  (often  of  the 
"post-it"  variety)  on  a  frequent  basis. 

It  is  recommended  that  early  in  system  development  the  issue  of  TIAPS  function  allocation 
between  the  two  member  team  be  examined  and  analysed  and  that  the  relationship  between 
TIAPS  functionality  and  other  standalone  systems  be  reviewed  for  potential  impact  on  overall 
workstation  configuration. 

While  a  number  of  the  above  issues  remain  to  be  identified  and  analysed,  we  have  made  the 
following  preliminary  observations  based  upon  the  information  obtained  to  date. 

4.7.4  Ambient  lighting 

The  overall  OMI  must  be  configured  by  taking  into  account  the  operational  ambient  illumination 
conditions.  Low  illumination,  red  lighting,  sources  of  screen  reflections  and  the  potential  for 
glare  all  will  have  an  impact  on  the  visual  quality  of  the  display.  Hence,  usability  analysis  and 
evaluations  of  the  OMI  should  generally  be  performed  in  a  context  that  allows  such  conditions  to 
be  simulated,  otherwise  the  results  may  not  be  valid  for  operational  conditions. 

4.7.5  Screen  configuration 

If  information  is  to  be  shared  among  the  two  operators  by  looking  at  each  other's  screens  from 
time  to  time,  or  if  other  team  members  will  need  to  look  "over-the-shoulder"  of  seated  operators, 
the  off-axis  viewing  of  the  display  becomes  an  important  issue.  Symbology,  graphics  and  text 
will  need  to  be  designed  in  a  manner  to  accommodate  such  conditions.  Further,  the  potential  use 
of  LCD  technology  may  exacerbate  such  problems. 

4.7.6  Software  navigation  issues 

By  software  navigation  we  are  referring  to  the  need  for  the  operator  to  move  purposely  through 
the  layers  and  menus  of  the  system  functionality  and  to  manage  windows  in  order  to  perform  the 
required  operational  tasks. 

One  potential  issue  that  may  be  readily  identified  is  how  the  operator  will  be  able  to  shift  between 
different  spatial  mental  models  of  the  maritime  picture.  For  example,  the  tactical  display 
provides  the  operator  with  a  high  level  view  of  the  tactical  situation  showing  an  integrated  view 
of  the  spatial  relationship  between  important  elements  of  the  tactical  environment.  If  operators 
are  provided  with  a  "zoom"  capability  that  allows  changing  the  scale  of  a  subset  of  the  tactical 
area  there  may  be  a  need  for  the  provision  of  separate  windows  for  providing  "ranged-in"  and 
"ranged-out  views.  As  a  second  example,  if  the  operator  wishes  to  explore  certain  aspects  of  a 
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contact’s  acoustic  data,  then  either  passive  or  active  display  formats  will  need  to  be  interrogated 
Since  these  formats  are  complex  (and  will  presumably  consume  a  large  component  of  screen 
area),  and  require  time  to  scroll  through,  explore  and  analyse  there  will  be  a  risk  associated  with 
losing  the  tactical  picture.  This  loss  may  take  a  variety  of  forms:  it  could  be  a  complete  or 
partial  loss  of  important  elements  from  the  mental  representation,  or  it  could  result  in  a  failure  to 
appreciate  how  the  tactical  picture  may  have  changed  in  the  time  between  the  operator's  last  view 
of  it  and  the  return  from  using  other  display  formats. 

At  this  stage,  this  concern  may  only  be  a  potential  area  to  be  flagged.  Several  design  decisions 
could  mitigate  this  risk.  For  example,  in  a  two-operator/two  workstation  configuration,  the 
tactical  display  could  always  be  maintained  on  one  of  the  operator's  consoles.  (This  assumes  that 
they  would  be  sufficiently  close  together  to  allow  appropriate  viewing  by  the  operator  who  may 
be  working  at  the  acoustic  data  level).  Another  approach  would  be  to  ensure  that  for  each 
workstation  that  there  is  adequate  screen  size  (or  two  screens)  to  always  allow  a  dedicated  area 
for  the  tactical  display. 

Notwithstanding  this  particular  solution  to  a  specific  issue,  there  remains  the  overall  problem  to 
ensure  that  the  operator's  mental  models  and  associated  situation  awareness  are  appropriately 
supported  as  the  operator  moves  through  different  aspects  of  the  system  functionality,  each  of 
which  provides  data  on  different  "world  views”.  Loss  of  the  picture,  problems  in  regaining  the 
picture  and  difficulty  integrating  spatial  and  other  data  across  a  variety  of  views  of  the  battlespace 
has  been  identified  as  a  major  issue  in  the  support  of  command  situational  awareness  and  decision 
making. 

4.7.7  Sharing  information 

We  have  concluded  from  previous  OR  analysis  (Matthews,  Webb  and  Bryant,  1999)  that  OR 
team  members  frequently  have  the  need  to  rapidly  share  spatial  information.  Sometimes  this 
relates  to  discussing  the  content  of  each  other's  display,  at  other  times  it  is  the  problem  of  how  to 
integrate  written  or  auditory  data  into  the  spatial  domain  of  the  user’s  current  mental  model. 

Some  of  the  specific  needs  that  have  been  identified  include: 

•  Rapidly  configuring  two  different  displays  to  ensure  a  common  displayed  area  of 
interest 

•  Tools  for  annotating  another  team  member's  display  (e.g.  to  easily  point  to  an  object 
of  interest) 

•  Tools  for  rapid  sharing  of  spatially  complex  data  (without  having  to  revert  to  long 
and  frequently  inaccurate  verbal  descriptions) 

These  needs  would  also  seem  relevant  to  the  future  implementation  of  TIAPS  as  an  operational 
system. 
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4.8  Future  research  and  development  issues  for  core  TIAPS  functions 
and  related  issues 

On  the  basis  of  the  information  available  at  this  stage  of  system  development,  the  following 
critical  functions  or  tasks  have  been  identified  as  being  candidates  for  future  research  and 
development  effort.  It  should  be  noted  that  this  list  represents  an  initial  assessment  that  will  need 
to  be  updated  and  modified  as  the  system  evolves  to  the  point  where  functions  are  allocated 
among  the  team  members,  and  any  new  operational  procedures  have  been  identified. 

4.8.1  Configuring  the  system 

In  TIAPS  there  will  be  a  number  of  critical  decisions  to  be  made  concerning  system 
configuration.  These  not  only  include  combining  the  existing  configuration  steps  for  separate 
active  and  passive  systems,  but  also  the  implications  of  any  interactions  and  synergies  to  be 
gained  by  the  dual  configuration  as  well  as  considerations  of  the  roles  to  be  played  and  tasks  to 
be  performed  by  the  two  sonar  team  members.  No  doubt,  over  time,  standard  configurations 
will  be  developed  for  particular  missions,  tactical  contexts  and  water  environments.  While  the 


Suggested  research  needs: 

1 .  Analyse  the  operator's  tasks  in  configuring  the  system  with  a  view  to  providing 
information  for  design  concepts  to  optimising  the  consistency  and  accuracy  of  the 
process. 


task  of  configuring  the  system  is  unlikely  to  be  performed  under  time  pressure  in  most 
circumstances,  it  is  one  that  will  need  to  be  performed  with  consistency  and  accuracy. 

4.8.2  Operator  interaction  with  automated  functions 

As  has  been  indicated  previously,  the  volume  and  scope  of  the  data  produced  by  TIAPS  creates  a 
serious  challenge  to  the  present  approach  in  CANT  ASS  for  contact  detection  and  analysis, 
whereby  the  operator  scrolls  through  processed  acoustic  data  on  a  beam-by-beam  basis.  The 
process  would  take  too  long  to  go  through  the  entire  beam  array  and  important  data  may  have 
arrived  on  any  beam  between  each  complete  scan.  As  a  consequence,  TIAPS  operates  on  the 
premise  that  certain  detection  and  tracking  functions  must  be  automated  and  the  operator  will 
monitor  the  output  of  such  processes.  It  should  be  remembered  that  this  output  will  be  dependent 
upon  not  only  the  characteristics  of  any  acoustic  sources  within  the  detection  range  but  also  on 
how  the  automated  processes  have  been  configured.  In  the  active  mode,  operators  must  select 
appropriate  transmission  characteristics  for  the  expected  targets  of  interest  as  well  as  configuring 
the  transmission  for  the  known  characteristics  of  the  water  environment.  The  operator  must  also 
set  up  the  criteria  and  parameters  for  automated  detectors.  The  operator’s  choice  of  a 
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transmission/detection  model4  is  critical  to  system  performance  and  represents  an  area  of 
functionality  that  has  not  been  investigated  in  the  present  study.  This  topic  seems  worthwhile  for 
future  analysis  because  of  the  potential  complexity  and  criticality  of  the  task.  For  example, 
setting  the  acoustic  propagation  model  requires  decisions  on  a  very  large  number  of  parameters, 
the  waveform  data  requires  14  parameters  to  be  set,  the  wavetrain  data  -5  parameters,  the  ping 
bundle  data  -12  parameters,  the  ping  sequence  data-12  parameters.  In  all,  there  appear  to  be 
somewhere  between  100  and  150  configuration  parameters.  While  many  of  these  will  be  pre¬ 
configured  and  pre-determined  into  a  standard  set  of  "models"  based  upon  accumulated 
operational  experience  and  the  tactical  situation,  this  type  of  function  represents  a  complex  series 
of  critical  tasks  which  will  require  close  analysis  to  determine  the  best  way  to  provide  functions, 
tools  and  an  OMI  to  allow  the  operator  to  perform  tasks  quickly  and  accurately. 

On  the  acoustic  reception  side,  the  operator  must  make  decisions  on  the  influence  of  the  water 
environment,  local  topography  and  range  of  interest.  Hence,  any  auto-detection  outcome  will  be 
influenced  both  by  how  well  the  system  has  been  configured  as  well  as  the  signal  to  noise  ratio  of 
the  acoustic  signal  of  interest.  To  state  the  obvious,  the  absence  of  a  signal  may  mean  either  that 
there  is  no  contact  present  or  that  the  system  has  not  been  configured  in  a  manner  to  detect  the 
contact.  Conversely,  the  presence  of  an  auto-detected  contact,  may  either  be  due  to  a  real  acoustic 
source  of  interest,  or  be  due  to  the  system  mistakenly  reporting  signal  in  the  presence  of  noise. 

In  deep  water  operations,  where  there  is  some  predictability  to  the  surrounding  underwater 
environment  and  acoustic  sources,  an  automated  system  may  work  with  a  high  degree  of 
effectiveness  in  yielding  high  hit  rates  while  minimising  false  alarms  and  misses.  However,  in  a 
littoral  environment,  particularly  in  areas  with  moderate  to  heavy  vessel  traffic,  it  may  be 
unrealistic  to  expect  that  an  automated  system  will  operate  with  the  same  level  of  effectiveness. 
Ironically,  it  is  exactly  in  such  an  environment  where  an  automated  system  is  needed  the  most,  in 
order  to  reduce  an  unmanageable  workload  on  the  operator,  because  of  the  high  volume  of 
acoustic  data  to  be  analysed. 

Operator  evaluation  of  the  detection  model 

In  order  to  understand  the  output  of  an  automated  process  in  such  a  context,  the  operator  (or,  as 
it  has  been  suggested,  the  supervisor)  will  have  the  task  of  establishing  "what  is  the  truth". 

There  may  be  two  possible  approaches  to  this.  First,  the  operator  could  systematically  explore 
and  evaluate  the  underlying  acoustic  data  on  which  the  automated  decision  has  been  made.  (In 
the  case  of  an  auto-detected  high  threat  target  this  kind  of  check  will  be  likely  mandated.)  The 
task  of  selecting,  scanning,  interpreting  and  analysing  the  underlying  data  associated  with  the 
contact  will  be  of  necessity  time  consuming.  In  terms  of  system  design,  this  suggests  that  there 
should  be  some  thought  given  to  how  the  underlying  data  may  be  readily  extracted  and  presented 
in  a  format  that  enables  rapid  understanding  and  interpretation  by  the  operator.  A  second  method 
for  establishing  the  validity  of  the  contact,  that  may  be  more  appropriate  when  the  operator  is 
looking  at  a  contact  summary  report  on  a  tactical  display,  would  be  to  allow  "what-if" 


4  The  term  detection  model  is  for  now  being  used  as  a  shorthand  to  summarise  all  of  the  operator 
selected  parameters,  whether  oceanographic,  tactical  or  intelligence-based  etc  that  will  be 
required  to  configure  both  active  and  passive  components. 
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exploration.  This  could  involve  giving  the  operator  the  ability  to  examine  changes  in  the 
displayed  plot  of  contacts  by  changing  model  parameters  in  real  time.  In  this  manner,  the 
operator  may  be  in  a  better  position  to  analyse  the  degree  to  which  the  automated  contact  reports 
are  influenced  by  critical  changes  in  any  of  the  underlying  model  parameters. 

For  either  of  these  methods  to  be  implemented,  there  will  be  a  need  for  research  into  first 
understanding  the  cognitive  tasks  that  the  operator  will  need  to  perform  to  establish  "truth  ",  and, 
second,  developing  display  formats  and  interactive  modes  that  support  the  operator's  cognitive 
requirements. 

Trust  in  automated  processes 

Experiences  from  other  domains  suggest  that  operator  trust  in  automaticity  is  critical  to  both  user 
acceptance  and  system  performance.  One  aspect  of  this  trust  concerns  the  reliability  of 
automated  systems.  Typically  three  kinds  of  unreliability  have  been  reported,  which  tend  to 
undermine  human  confidence.  First,  the  automated  processes  may  fail,  since  frequently  they  are 
more  complex  than  the  equivalent  human  activities  (Wickens,  1992).  Second,  human  operators 
may  incorrectly  (and  unwittingly)  configure  system  parameters  (e.g.  Stein,  1981).  Third,  the 
automated  system  performs  as  it  is  supposed  to,  but  the  operator  fails  to  understand  it  and 
assumes  that  it  is  making  errors  (Woods,  1996). 

In  the  case  of  automated  sonar  detection  systems,  errors  are  an  inherent  by  product  of  any 
detection  algorithm.  Acoustic  data  are  by  their  very  nature  uncertain  and  noisy  and  there  will 
always  be  an  overlap  between  the  distribution  of  acoustic  data  that  represent  noise  and  the 
distribution  of  acoustic  data  that  represents  contact  superimposed  on  noise.  Thus,  with  any 
automated  system  designed  to  make  decisions  on  "contact"  or  "non-contact"  there  will  be  errors 
depending  upon  where  the  decision  criterion  is  placed.  Errors  will  either  be  missed  contacts  or 
false  positive  identifications  of  noise  as  contacts.  The  frequency  of  such  errors  establishes  the 
level  of  operator  trust  in  the  system.  In  existing  operations  using  CANTASS,  operators 
frequently  turn  off  automated  trackers,  because  they  tend  to  increase  workload  by  generating 
false  tracks  instead  of  reducing  workload  as  intended.  Further,  recent  studies  show  that 
operators  may  set  the  criterion  threshold  of  an  automatic  detector  and  tracker  to  minimise 
workload  rather  than  optimise  performance  (McFadden,  Lauz  and  Stanger,  in  preparation) 

Even  if  new  generations  of  detectors  and  processing  algorithms  reduce  the  number  of  perceived 
operational  errors,  there  remains  the  possibility  that  another  problem  associated  with  human  trust 
might  emerge,  namely  overconfidence  or  reliance.  Some  of  the  issues  of  operator 
overconfidence  in  system  automation  that  give  rise  to  complacency  and  lack  of  vigilance 
(Parasuraman,  1986),  would  not  seem  to  be  applicable  to  the  potentially  high  threat  context  of 
many  naval  subsurface  operations.  However,  research  which  shows  a  loss  in  situation 
awareness,  when  operator's  cease  to  become  active  processors  of  data  and  over  rely  on 
automation  (Hopkin,  1996)  may  be  relevant.  This  may  produce  some  somewhat  contradictory 
guidance  for  the  adoption  of  automation,  since  if  operators  alone  are  required  to  process  all  of 
the  sonar  data  without  machine  assistance,  this  in  itself  will  tend  to  inhibit  the  formation  of 
situation  awareness.  Operators  may  tend  to  spend  too  much  time  "in  the  weeds"  without  seeing 
the  larger  tactical  picture.  Traditionally,  this  problem  has  been  solved  by  role  differentiation 
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within  the  OR  team  hierarchy,  whereby  operators  detect,  identify  and  to  some  extent  classify  and 
feed  the  processed  information  to  higher  levels  in  the  command  team  to  build  the  tactical  picture. 

The  research  literature  also  shows  that  operator  trust  in  automated  systems  is  frequently  out  of 
calibration  and  there  is  reported  evidence  of  both  over-trust  and  mistrust.  Humans  tend  to  trust 
their  own  performance  over  that  of  automated  systems,  even  when  the  automated  system 
performs  at,  or  better,  than  its  human  counterpart  (Liu,  Fuld  and  Wickens,  1993).  In  particular, 
the  literature  on  mistrust  of  alarm  systems  may  be  particularly  relevant  to  automated  sonar 
detectors  that  are  designed  to  alert  the  operator  to  hostile  or  other  potentially  threatening  contacts 
of  interest.  This  literature  shows  that  operators  may  so  mistrust  unreliable  warning  systems  that 
legitimate  warnings  are  ignored  (Sorkin,  1988). 

While  proper  training  and  operational  experience  may  reduce  some  of  the  problems  associated  with 
trust  and  interpretation,  there  will  remain  the  requirement  for  the  operator  to  be  able  to  interrogate 
the  veracity  of  any  automated  process.  Hence,  in  designing  the  system  some  consideration  may 
need  to  be  given  to  providing  information  to  the  operator  concerning  the  implications  of  the  chosen 
decision  criterion  for  generating  false  positive  or  missed  contact  errors,  particularly  as  a  function  of 
the  influence  of  the  local  environmental  conditions.  McFadden,  Vimalachandran  and  Blackmore, 
(2001)  showed  that  subjects  in  a  simulated  sonar  detection  and  tracking  task  failed  to  detector  errors 
by  the  automated  detector  and  tracker.  They  suggested  that  such  failure  was  due  largely  to  the  lack 
of  visibility  of  the  automation  errors  relative  to  other  errors.  They  further  showed  that  people  could 
make  reasonably  effective  use  of  an  automated  tracking  system,  if  they  receive  extensive  experience 
with  it.  However,  just  training  people  on  the  associated  manual  task  appeared  to  be  of  little  benefit. 
Thus,  it  seems  desirable  to  provide  operators  with  some  easily  comprehensible  feedback  on 
probability  of  each  error  type  for  the  given  context,  and  to  ensure  that  they  are  appropriately 
trained  to  actually  use  this  information  in  under  actual  operational  conditions.  This  training  would 
involve  developing  skills  at  setting  appropriate  criteria  for  the  context,  monitoring  the  system  for 
automation  errors  and  interpreting  the  operational  significance  and  reliability  of  the  data  obtained 
from  automated  processes. 

Some  general  principles  for  improving  the  trust  between  the  human  operator  and  automated 
processes  are: 

Keep  the  human  informed  by  advising  what  the  automation  is  doing  through  readily 
comprehended  displays. 

Keep  the  human  trained  in  order  to  maintain  the  necessary  skill  level 

Keep  the  operator  in  the  loop.  Getting  the  right  level  of  operator  involvement 
represents  a  significant  design  challenge  to  avoid  the  extreme  conditions  of  operator 
overload  and  underload  and  complacency. 
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Make  the  automation  flexible  and  adaptive  in  order  to  allow  for  different  levels  of 
operator  involvement  depending  upon  the  workload  demands  of  the  context  and  to 
accommodate  differences  between  operators. 


Suggested  research  needs: 

1.  Analyse  the  operator's  tasks  in  configuring  automated  processes  and  comprehending  of 
the  impact  of  the  configuration  setting  upon  the  expected  data. 

2.  Analyse  the  operator's  understanding  of  the  performance  tradeoffs  associated  with 
criterion  settings  for  automated  functions.  (Note:  this  will  require  that  appropriate 
prototype  system  functionality  be  in  place  to  create  the  necessary  test  capability.  Such 
functionality  would  then  be  re-configured  in  system  development  as  part  of  a  recursive 
process  of  test  and  evaluation). 

3.  Conduct  research  on  the  best  way  to  provide  a  visual  or  data  representation  of  the 
information  that  will  support  the  operator's  mental  model  for  making  effective  decisions 
concerning  both  of  the  above  areas. 

4.  Perform  a  literature  review  to  determine  whether  there  is  relevant  research  in  other 
domains  concerning  operator  trust  in,  and  interaction  with,  automated  systems  with  a 
view  to  acquiring  guidance  on  specific  design  solutions  that  address  issues  of  operator 
trust  and  performance. 


4.8.3  Displaying  the  tactical  underwater  environment 

Existing  passive  and  active  displays  of  process  sonar  data  do  not  lend  themselves  well  to  rapidly 
producing  a  level  of  understanding  or  comprehension  in  the  sonar  operator  (NATO  IST-13/TG- 
002,  1999).  Existing  displays  require  operators  to  perform  labour  intensive  tasks  to  analyse  and 
transform  data  in  order  to  comprehend  its  significance.  Further,  it  will  be  particularly  important 
for  operators  to  have  a  clear  and  rapid  understanding  of  the  underwater  environment  for 
operations  in  the  fast  changing  context  of  a  littoral  environment.  Recent  papers  (e.g.  Wright, 
2000)  suggest  new  ways  of  modelling  the  underwater  environment  to  assist  the  process  of 
visualising  aspects  of  the  topography,  water  and  temperature  layers  and  tactical  context.  These 
methods  provide  the  operator  with  a  visual  model  of  the  environment  that  maps  more  directly  on 
to  their  cognitive  framework  than  traditional  displays.  One  application  area  that  could  be 
developed  concerns  new  display  formats  that  show  acoustic  propagation  and  dispersion  data 
(either  active  or  passive)  superimposed  upon  topographical  and  water  layers  as  a  3d  model. 
Given  that  it  is  important  that  the  operator  understand  how  these  elements  influence  the  sonar 
data  that  is  obtained,  such  a  display  format  might  more  easily  support  the  operator's  mental 
model  of  the  UW  environment.  This  could  also  be  refined  to  incorporate  aspects  of  the  acoustic 
volume  analyser  (Wright  2000). 
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Suggested  research  needs: 

1 .  Conduct  a  cognitive  task  analysis  to  determine  operator  needs  for  comprehending  the 
underwater  environment. 

2.  Review  literature  on  visualisation  techniques  for  representing  the  underwater 
environment. 

3.  Evaluate  data  formatting  and  presentation  options  for  optimising  visualisation  of  the 
underwater  environment,  including  colour  coding  and  3d  representations. 

Suggested  design/development  needs: 


4.8.4  Operator  interaction  with  the  tactical  display 

In  this  section  we  speculate  on  the  multiple  roles  that  could  be  played  by  the  tactical  display  in 
supporting  UW  picture  compilation  and  tactical  decision  making.  By  examining  possible  worst- 
case  scenarios  for  the  use  of  the  tactical  display  at  this  stage  in  system  development,  we  flag 
opportunities  to  conduct  appropriate  research  and  design  activities  at  the  appropriate  stage  of 
system  evolution  and  before  operational  introduction. 

At  present  it  is  not  known  how  the  UW  team  responsibilities  may  change  with  the  introduction  of 
TIAPS.  However,  for  present  purposes,  it  may  be  appropriate  to  consider  that  the  ASWC  will 
retain  the  responsibility  of  working  with  the  ORO  at  the  tactical  decision  making  level,  while  the 
team  below  the  ASWC  ensures  that  the  appropriate  and  correct  UW  picture  is  being  fed  to  the 
command  level.  Hence,  a  critical  common  point  of  focus  between  the  ASWC  and  other  team 
members  (probably  the  supervisor)  becomes  the  tactical  display.  While  the  ASWC  may  have  an 
additional  tool  suite  to  configure  the  tactical  display  to  assist  tactical  decision  making,  the  basic 
UW  picture  will  be  determined  at  the  supervisor  level.  Thus,  all  contacts  that  are  displayed  will 
need  to  have  been  appropriately  analysed  and  annotated.  Further,  if  the  intention  is  to  use  the 
tactical  display  for  showing  the  RMP,  every  contact  will  need  to  be  identified.  Thus,  one  role 
for  the  common  tactical  display  is  to  represent  the  RMP. 

A  second  role  of  the  tactical  display  is  to  present  to  the  operator  the  ongoing  data  associated  with 
automatic  contact  detection  and  tracking  systems.  The  operator  will  have  the  task  of  searching 
for  new  contacts  (which  will  become  increasingly  complex  with  larger  numbers  of  targets  and 
busy  littoral  environments)  and  ensuring  targets  are  appropriately  tracked. 

A  third  role  of  the  tactical  display  may  be  to  allow  the  operator  to  conduct  some  forms  of 
analysis  concerning  the  veracity  of  auto-detected  contacts,  as  well  as  to  identify,  localise  and 
classify.  In  this  role,  the  tactical  display  and  associated  tools  provide  the  operator  with  the 
capability  of  looking  at  the  relationship  between  contacts  and  other  relevant  elements  from  the 
UW  environment. 
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A  major  difficulty  can  be  foreseen  in  the  interaction  of  the  different  display  requirements  for 
these  three  different  roles.  For  detecting  new  contacts,  the  supervisor  will  need  the  symbology 
that  facilitates  rapid  localisation  of  the  contact  on  the  display.  For  analysing  the  contact,  the 
supervisor  will  need  to  rapidly  access  contact  characteristics  and  compare  these  with  associated 
or  correlated  data  available  through  other  display  formats  (e.g.  broad  band).  For  building  the 
RMP,  the  supervisor  will  need  to  ensure  that  each  track  is  appropriately  configured  and 
annotated.  A  scenario  could  be  envisaged  in  a  busy  littoral  environment,  where  scores  of  auto- 
detected  contacts  are  plotted  on  the  display  already  populated  with  track  data  as  part  of  the  RMP. 
The  operator  may  face  two  major  challenges  such  circumstances.  First,  the  task  of  detection  new 
contacts  may  be  visually  challenging  among  the  clutter;  second,  if  the  operator  changes  focus 
from  the  tactical  display  to  the  task  of  analysing  acoustic  contacts  using  other  displays,  it  may  be 
difficult  to  determine  what  has  changed  in  the  tactical  display  when  it  is  again  the  focus  of 
attention. 


The  information  requirements  that  subserve  each  of  these  functions  to  be  performed  using  the 
tactical  display  are  likely  to  be  different  since  they  involve  all  of  the  different  perceptual 
operations  outlined  in  IST-13/TG-002  (1999),  i.e.  controlling/monitoring,  alerting,  searching  and 
exploring.  Examples  of  these  are: 

Monitoring :  sampling  the  surrounding  acoustic  environment  to  monitor  variables  that 

influence  model  parameter  values. 

Controlling:  building  the  UW  RMP 

Alerting:  scanning  the  display  for  high  threats  or  pop-up  contacts 


Searching:  scanning  the  display  for  new  contacts  displayed  as  output  from  automated 
processes 

Exploring:  broadly  searching  the  tactical  area  of  interest  to  gather  information  on  any 
new  data  of  interest  that  might  influence  the  tactical  picture  or  enhance  processes  of 
identification  and  classification. 


As  stressed  in  IST-13/TG-002  (1999),  these  different  perceptual  processes  each  require  different 
forms  of  data  display,  transformation  and  coding  in  order  to  support  rapid  and  accurate 
comprehension  of  the  information. 

Finally,  given  the  many  potential  roles  to  be  performed  by  the  tactical  display,  it  seems  likely 
that  the  operator  or  supervisor  will  be  faced  with  new  tasks  associated  with  display  management. 
While  this  may  be  considered  a  minor  issue  at  the  present  stage  of  development,  other  complex 
systems  which  use  multiple  display  formats  on  a  single  physical  display  have  been  shown  to 
induce  user  confusion  and  resulting  performance  errors,  typically  when  operators  are  under  stress 
and  have  moderate  to  high  workloads  (Sarter  and  Woods,  1995). 
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Suggested  research  needs: 

1 .  Develop  mission  scenarios  for  assessing  the  impact  of  TIAPS  on  future  operations. 

2.  Perform  further  task  and  function  analysis  to  determine  the  operational  functions  to  be 
performed  by  the  UW  team  (ASWC,  Supervisor,  Operator)  using  the  tactical  display.  In 
particular  determine  whether  the  UW  RMP  will  be  compiled  on  the  display,  and  who  in 
the  team  will  have  the  responsibility  for  this  task. 

3.  Develop  a  taxonomy  of  user  visual  performance  tasks  and  modes  of  data  representation  to 
provide  guidelines  for  appropriate  display  formats  and  configurations. 

4.  Determine  the  degree  to  which  the  potentially  different  representations  for  the  tactical 
display  can  be  accommodated  within  a  single  window  format,  or  whether  multiple 
representations  are  required. 


4.8.5  Communicating  spatial  information 

Many  of  the  tactical  decisions,  whether  in  the  underwater  or  above  water  domain,  depend  upon  a 
rapid  comprehension  of  elements  of  time  and  space  within  and  across  team  members  (Matthews, 
Webb  and  Bryant,  1999)  and  current  C2  technologies  in  the  CPF  do  not  support  this  function 
well.  Frequently,  the  team  mental  model  of  the  tactical  situation  requires  a  common 
understanding  of  spatial  information  that  can  be  readily  visualised.  Team  members  may  also 
need  to  share  a  common  picture,  often  from  a  common  perspective  (e.g.  range,  zoom  and  point 
of  focus)  with  common  elements  integrated  with  individual  annotations  that  are  relevant  to 
understanding  the  situation  and  deciding  among  action  options.  As  new  technologies  like  TIAPS 


Suggested  research  needs: 

1 .  Perform  cognitive  task  analysis  to  determine  the  shared  information  needs  among  UW 
team  members  and  higher  command  levels. 

2.  Determine  whether  existing  guidelines  are  adequate  for  determining  the  specific  format 
and  structure  of  data  representations  to  facilitate  rapid  spatial  information  sharing. 

3.  Empirically  evaluate  effective  means  of  visually  representing  common  information  based 
upon  guidelines  or,  if  required,  new  research  initiatives. 

4.  More  generically,  conduct  research  on  how  team  members  communicate  and  share  spatial 
information  and  the  nature  of  internal  representations  and  develop  conceptual  models  and 
guidelines. 


migrate  into  the  operational  environment,  with  their  improved  capability  for  displaying  common 
information  and  sharing  data  among  the  command  team  and  lower  levels  in  the  hierarchy,  an 
opportunity  exists  to  provide  improved  functionality  for  sharing  spatial  information. 
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4.8.6  Function  allocation  and  UW  team  composition 

At  present,  as  a  technology  demonstration  project,  there  has  been  a  focus  in  TIAPS  on  providing 
new  tools  and  functionality  to  assist  sonar  operations.  Some  decisions  have  been  made 
concerning  the  allocation  of  functions  to  machine  or  human  that  are  thought  to  optimise  the  roles 
of  each.  These  decisions  have  been  made  in  a  system  development  context  rather  than  as  a  result 
of  a  formal  function  allocation  exercise.  The  future  structure  of  the  sonar  team  and  its 
relationship  to  the  command  level  structure  is  also  not  known  at  this  time,  although  there  is 
persistent  speculation  that  the  number  of  personnel  in  the  future  is  likely  to  be  lower  than  at 
present.  Given  the  potentially  broad  range  of  functionality  provided  by  TIAPS  and  the  need  to 
consider  a  more  streamlined  personnel  environment,  there  will  soon  be  a  critical  need  to  assess 
function  allocation  not  only  between  machine  and  human,  but  also  among  the  team  members.  It 
is  possible  that  some  tasks  now  performed  at  the  ASWC  level  or  by  other  sonar  team  members 
(e.g.  building  the  RMP,  localisation  and  TMA)  will  need  to  be  performed  within  the  TIAPS 
team.  To  assist  the  process  of  determining  the  implications  of  different  allocations,  task  network 
modelling  of  different  arrangements  is  recommended. 


Suggested  research  needs: 

1.  Develop  a  task  network  simulation  of  the  TIAPS  functions,  including  other  generic  UW 
C2  functions  as  necessary. 

2.  Evaluate  the  impact  of  different  numbers,  roles  and  responsibilities  of  the  UW  team 
composition  on  information  flow,  workload  and  the  performance  of  critical  tasks. 

3.  Determine  the  optimum  composition  of  the  UW  team  and  functions  assigned  to  each  team 
member. 


4.8.7  Miscellaneous  display  issues 

As  outlined  in  the  heuristic  review  of  the  tactical  display  a  number  of  research  and  design  issues 
were  identified  and  these  are  summarised  below. 


Suggested  research  needs: 

1 .  Do  link  analysis  and  other  relevant  analyses  to  determine  optimal  workstation  layout 

2.  Evaluate  impact  of  LCD  technology  for  off  axis  and  low  illumination  viewing 

3.  Develop  guidelines  for  OMI  style  for  LCD  technology,  in  particular,  taking  into  account 
issues  of  display  resolution,  colour  coding,  text  and  symbology. 

4.  Determine  appropriate  screen  layouts,  formats  and  navigation  for  supporting  TIAPS 
functionality. 
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5.  Discussion 


In  considering  the  analysis  of  OMI  issues  relating  to  TIAPS,  it  must  always  be  remembered  that 
TIAPS  is  a  technology  demonstration  in  an  ongoing  state  of  development.  Unlike  a  commercial 
product,  which  is  designed  to  pre-determined  specifications,  TIAPS  represents  a  research  and 
development  vehicle  to  assess  the  feasibility  of  new  approaches  to  sonar  data  processing.  A 
major  question  is  then  -  at  what  stage  of  maturity  of  development  does  it  make  sense  to  conduct 
function  analysis,  specify  critical  tasks  and  evaluate  the  OMI?  If  performed  too  early  in  system 
development  the  analysis  may  be  inappropriate  in  that  the  functionality  and  technology  at  the  time 
of  the  analysis  may  only  represent  interim  working  ideas  that  will  give  way  to  possibly  new 
directions.  If  performed  too  late,  then  hard  design  decisions  may  have  been  made  without 
considering  the  role  of  the  user,  and  which  may  be  costly  and  impractical  to  undo. 

While  it  may  be  argued,  that  the  function  analysis  should  be  independent  of  the  system,  radical 
advances  in  technology  may  profoundly  influence  what  functions  a  system  can  perform,  which  in 
turn  impact  upon  the  operator's  tasks.  Further,  new  technologies  may  so  transform  the  situation 
that  they  will  inevitably  impact  upon  doctrine,  staffing,  function  allocation  and  operational 
procedures.  Thus,  it  would  appear  that  one  can  never  fully  separate  the  "true"  system  functions 
from  the  underlying  technology.  What  the  operator  can  and  will  do  will  always  to  some  extent 
depend  on  the  capabilities  of  the  technology.  This  means  that  mission,  function  and  task 
analyses  may  become  continuing  and  iterative  processes  throughout  system  development  in 
contrast  to  the  traditional  approach  of  doing  them  early  and  one  time  only.  However,  one  would 
expect  that  with  each  iteration,  the  analysis  would  be  refined  rather  than  redone  (with  consequent 
reduction  from  the  initial  level  of  effort)  and  at  the  mission  analysis  level  there  may  be  little  need 
for  more  than  one  or  two  iterations.  In  general,  to  define  the  basic  functions  of  military  C2 
systems  that  embrace  revolutionary  technology,  means  that  there  has  to  be  a  continuing  high  level 
of  synergy  during  the  development  and  evaluation  process  among  the  technology  designers, 
research  scientists,  human  factors  specialists  and  military  users.  Among  the  latter  it  will  be 
necessary  to  engage  involvement  of  SMEs  with  a  range  of  perspectives,  including  the  doctrinal, 
the  procedural  and  the  operational,  that  may  be  impacted  by  technological  considerations. 

If  one  regards  the  present  analysis  as  being  the  first  step  in  the  iterative  function  specification 
cycle,  then  given  that  there  has  been  significant  interaction  with  scientific  and  development 
SMEs,  and  some  access  to  current  TIAPS  functionality,  it  may  be  reasonable  to  conclude  that  the 
timing  is  appropriate.  At  this  stage,  the  system  concept  is  reasonably  well  defined,  core 
functionality  is  in  place  and  operational  trials  to  assess  the  technical  aspects  of  sonar  data 
processing  are  in  progress.  Having  said  this,  it  should  be  noted  that  the  primary  focus  in  the 
short  term  among  the  TIAPS  team  is  to  evaluate  the  major  steps  forward  that  have  been  taken 
with  new  technology.  The  role  of  the  operator  right  now  is  more  of  a  product  tester  than  an 
operational  sonar  operator.  As  such,  the  OMI,  at  this  stage  of  system  development,  may  only 
need  to  be  sufficient  to  enable  the  collection  of  acoustic  processing  performance  data. 

Following  the  earlier  argument,  it  should  be  concluded  that  the  function  and  heuristic  analysis 
represents  an  interim  evaluation  of  TIAPS.  Sufficient  functionality  exists  in  concept  form  to 
comment  upon  how  it  may  be  structured  to  perform  operational  tasks.  Limited  interactive _ 
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functionality  also  permits  some  initial  evaluation  of  OMI  concepts.  Instead  of  regarding  the 
current  analysis  as  a  final  statement  on  TIAPS,  it  should  be  seen  against  the  context  of  the 
general  development  philosophy  of  "build  a  little,  test  a  little"  -  to  which  we  should  probably  add 
the  phrase  "analyse  a  little".  If  the  existing  functionality  undergoes  major  changes  in 
development,  it  may  be  necessary  to  revisit  the  function  analysis.  Certainly,  as  new  functionality 
is  translated  into  working  interfaces,  additional  OMI  evaluation  will  be  required.  Such  future 
work  will  be  facilitated  by  the  existence  of  the  present  analyses.  The  function  analysis  provides 
a  basic  structure  on  which  to  build  future  elements  and  change  relationships  among  existing 
functions.  The  heuristic  review  of  the  OMI  has  produced  some  principles  that  should  generalise 
to  future  work.  Perhaps,  the  most  significant  impact  on  the  need  for  future  function  analysis  will 
come  from  an  operational  review  of  how  TIAPS  functionality  will  actually  be  adapted  in  the  OR. 

This  larger  issue  of  how  TIAPS  will  fit  in  with  new  command  philosophies,  tactical  doctrine, 
team  roles,  responsibilities  and  personnel  levels  will  have  a  major  influence  on  how  TIAPS 
functionality  will  be  actually  implemented.  For  example,  with  a  smaller  team  and  responsibility 
for  creating  the  UW  RMP  delegated  downwards,  the  role  of  the  sonar  operator  will  be  very 
different  from  existing  practices.  As  a  consequence,  the  functions  and  underlying  tasks  will 
change.  This  will  require  not  only  revision  of  the  function  analysis  but  will  have  implications  for 
function  allocation  and  the  design  of  the  tactical  display.  To  some  extent  this  report  tries  to 
anticipate  such  possibilities  and  therefore  flags  issues  in  OMI  design  that  may  need  to  be 
considered  to  meet  such  needs.  However,  given  the  radical  departure  from  existing  operator 
tasks  and  practices  that  could  be  envisaged  with  TIAPS,  there  will  be  a  critical  need  to  evaluate 
candidate  OMI  designs  in  an  evolutionary  manner  -  from  storyboard  through  field  testing 
(Matthews,  Webb  and  McCann,  1997).  At  present,  such  a  process  does  not  appear  to  be  on  the 
horizon  of  TIAPS  development,  given  the  interim  focus  on  ensuring  that  the  underlying 
technology  is  sound. 

Finally,  there  will  be  a  need  for  Navy  involvement  in  defining  what  role  they  want  the  sonar 
operator  to  play,  in  the  light  of  the  functional  design  philosophy  that  is  involving  under  TIAPS. 
The  current  design  solutions  have  significant  implications  for  manning,  job  role  definition  and 
training  of  the  UW  team  in  the  Ops  Room.  Failure  to  bring  the  operational  and  design 
perspectives  together  at  this  time  of  system  development  may  lead  to  a  fundamental  conflict 
between  technology  and  command  authority  .  (Pigeau  and  McCann,  in  preparation).  A 
development  strategy  in  which  there  is  an  over-emphasis  on  advancing  specific  sonar 
technologies  without  a  parallel  consideration  of  how  solutions  might  impact  on  the  structure  of 
the  operations  room  creates  an  environment  where  such  conflict  is  likely  to  emerge.  Failure  to 
recognise  the  operational  implications  of  current  design  decisions  will  lead  to  the  operator  not 
using  the  system  to  its  full  potential,  just  as  certainly  as  poor  design  of  the  interface.  An  example 
of  this  is  the  failure  of  operators  to  make  effective  use  of  the  current  automation  capability  in  the 
CCS  and  CANTASS. 

In  contrast,  the  bringing  together  of  Navy  operational  interests  and  HF  analysis  and  evaluation 
with  the  main  thrust  of  the  technology  development  has  the  potential  to  yield  many  benefits. 

Navy  analysts  will  have  an  early  appreciation  of  how  the  new  technology  will  impact  on 
operational  procedures  and  can  consequently  feed  back  to  the  development  team  how  the  system 
functionality  may  need  to  be  configured  to  meet  new  procedures  and  manning.  The  HF  role  will 
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be  to  interpret  the  human  performance  considerations  that  derive  from  the  ensuing  functions  in 
terms  of  analysing  tasks,  assessing  function  allocation  trade-offs  between  the  operator  and  the 
system  and  advising  on  resulting  OMI  issues  that  will  be  critical  for  effective  human-system 
performance.  Early  and  ongoing  involvement  of  the  three  groups  will  also  ensure  that  design 
options  are  considered  and  evaluated  before  system  functionality  becomes  too  firmly  established 
with  the  inevitable  higher  level  of  effort  and  costs  for  revision. 

The  complexity  of  the  technology  and  its  potential  to  be  a  revolutionary  rather  than  evolutionary 
approach  to  UW  warfare  demands  such  a  synergistic  approach  to  system  development  that  falls 
outside  the  norm  of  typical  commercial  product  development  strategies.  The  successful  evolution 
of  system  functionality  will  be  dependent  upon  the  ability  to  bring  together  the  design  and  build 
process  with  test,  evaluation  and  research  activities.  While  some  of  the  questions  concerning 
function  allocation  and  OMI  design  can  be  anticipated  and  answered  within  the  existing 
knowledge  base,  many  other  questions  will  require  that  system  functions  be  analysed  with 
human-in-the-loop  tasks  and  experimental  protocols.  This  analysis  may  then  uncover  issues  for 
which  there  needs  to  be  some  core  HF  research  in  order  to  provide  data  to  inform  the  optimum 
design  solutions.  Further,  at  some  point  in  system  development  there  will  be  a  need  to  obtain 
estimates  of  human  workload  issues  and  performance  capabilities  for  critical  tasks  by  evaluating 
design  alternatives  and  function  allocation  trade-offs  using  methods  such  as  task  network 
simulation.  The  resulting  information  will  provide  meaningful  feedback  to  both  functional  design 
and  detailed  OMI  design. 

Let  us  now  summarise  and  review  the  major  issues  revealed  by  the  HF  analyses  in  terms  of  the 
core  critical  tasks  and  functions. 

One  of  the  largest  issues  concerns  the  role  and  performance  of  the  operator  in  working  with  an 
automated  system.  Experience  in  other  domains  shows  that  automation,  while  often  reducing 
some  forms  of  workload  for  the  operator,  creates  other  impairments  to  effective  human-system 
co-operation.  Experience  in  CANTASS,  where  some  of  the  automated  functions  are  not  used  by 
operators,  is  consistent  with  automation  research  that  shows  users  will  not  use  automated  systems 
unless  they  are  perceived  as  trustworthy  and  as  reducing  workload.  The  report  identifies  several 
related  issues  that  will  need  detailed  design  attention  as  the  system  evolves.  These  include 
operator  trust  in  automation,  operator  configuration  and  analysis  of  automated  processes,  and  the 
shift  from  the  current  role  of  the  operator  as  an  active  data  processor  to  the  role  of  part  active 
processor  and  part  system  monitor.  Careful  review  of  these  areas  will  be  needed  to  ensure  that 
the  appropriate  functionality  is  in  place  to  meet  the  operator's  needs  and  that  the  functionality  is 
supported  by  an  OMI  that  allows  rapid  comprehension  by  the  operator  of  critical  information. 

A  second  major  area  concerns  the  configuration  of  system  models  and  interpretation  of  their 
performance.  While  this  is  not  a  new  functionality  in  sonar  operations,  it  does  represent  a  core 
process  for  elements  of  both  active  and  passive  sonar  analyses.  There  is  a  requirement  for 
operators  to  be  able  to  configure  effectively  and  to  readily  understand  the  implications  of  choices 
that  are  made.  The  criticality  of  this  task  will  be  enhanced  with  future  operations  in  littoral 
contexts. 

A  third  area  concerns  the  function  and  design  of  the  tactical  display.  It  has  been  shown  that  the 
inherent  flexibility  provided  by  the  functionality  of  the  tactical  display,  means  that  the  display 
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will  be  useful  for  a  range  of  operational  tasks.  However,  each  of  these  tasks  may  require 
different  design  approaches  to  the  OMI.  A  format  that  is  optimised  for  building  the  RMP  may  be 
inappropriate  for  detection  of  contacts,  classification  or  tactical  analysis.  A  balanced  and  flexible 
design  approach  will  be  required  to  ensure  that  in  making  the  tactical  display  serve  a  broad 
variety  of  needs  that  it  also  supports  in  an  optimum  manner  any  specific  need.  Additional 
analyses  will  be  needed  to  uncover  the  specific  design  requirements,  once  operational  functions 
for  the  display  have  been  explored  and  determined. 

A  fourth  area  concerns  how  the  overall  workstation  configuration  and  each  functional  window 
will  be  integrated  to  serve  operational  requirements.  Of  concern  is  the  loss  of  situational 
awareness  that  can  occur  when  an  operator  has  to  switch  between  types  and  levels  of  display 
information.  For  example,  the  operator  may  "lose"  details  of  the  tactical  picture  when  doing 
tasks  that  involve  analysis  of  processed  sonar  data,  association,  track  management  or  TMA. 
Further,  when  trying  to  regain  the  tactical  picture  after  performing  such  tasks,  the  operator  has  to 
have  a  rapid  comprehension  of  what  has  changed.  While  some  of  these  issues  may  be  resolved 
by  assignment  of  different  and  specialised  roles  for  each  of  the  UW  team  members  (as  is 
presently  the  case),  the  convergence  of  powerful  functionality  within  the  TIAPS  suite  together 
with  a  reduction  in  personnel  will  inevitably  result  in  an  environment  where  operator  multi¬ 
tasking  becomes  the  norm. 

A  fifth  area  deals  with  general  screen  design  issues.  While  ultimately  individual  screen  designs 
will  be  dictated  by  the  specific  operational  tasks  that  will  emerge,  certain  issues  can  be  identified 
at  this  stage  in  system  evolution.  First,  there  are  basic  symbology,  data  and  colour  coding  issues 
that  will  be  influenced  not  only  by  operator  needs  but  also  the  display  technology  adopted. 

Second,  there  are  more  generic  issues  about  how  to  design  displays  that  support  tasks  such  as 
setting  and  interpreting  system  models  and  evaluating  the  performance  of  automated  systems. 
Third,  there  are  issues  about  how  to  improve  operator  visualisation  of  the  underwater  physical 
environment  both  from  the  perspective  of  analysis  of  sonar  performance  and  evaluation  of  the 
tactical  situation.  This  need  will  become  more  critical  with  operations  in  littoral  environments. 
Fourth,  there  is  a  need  to  provide  tools  that  will  improve  the  effectiveness  of  the  conduct  of  tasks 
such  as  contact  identification,  localisation  and  classification  to  take  advantage  of  the  improvement 
in  the  underlying  acoustic  data  that  TIAPS  will  afford.  References  are  provided  in  the  text  for 
some  generic  guiding  principles  that  address  OMI  design  to  support  user  comprehension  of 
spatio-temporal  information  through  visualisation  (e.g.  NATO  IST-13/TG-002,  1999). 

However,  research  in  this  area  is  insufficiently  developed  at  this  stage  to  provide  the  TIAPS  team 
with  concrete  guidelines  for  specific  display  design. 

To  continue  this  theme,  the  report  notes  a  number  of  areas  where  future  research  is  needed  in 
order  to  provide  data  and  recommendation  to  support  TIAPS  design  and  development.  It  is  also 
recommended  that  some  of  the  design  options,  alternatives  for  function  allocation  to  system  and 
operator  (and  between  operators)  be  analysed  using  a  task  network  simulation. 

Finally,  it  is  recommended  that  the  functional  analysis  and  OMI  review  be  considered  integral  to 
the  future  design  and  development  cycle  of  TIAPS.  The  present  analysis  provides  a  foundation 
and  structure  to  facilitate  such  future  tasks.  However,  as  operational  considerations  start  to  shape 
the  roles  to  be  played  by  the  UW  team  using  a  future  version  of  TIAPS ,  as  new  core 
functionality  emerges,  and  as  tools  and  features  for  analysis  and  interpretation  of  sonar  data  are 
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developed,  there  will  be  a  need  to  ensure  that  appropriate  HF  analyses  are  performed  of  the 
OMI.  This  will  typically  involve  an  iterative  process  through  storyboarding  of  early  concepts, 
interactive  user  evaluation  of  interim  design  solutions  and  empirical  evaluation  of  prototype 
systems  with  human  in  the  loop  tasks. 
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6.  Summary  of  Recommendations 


In  this  section  recommendations  made  in  the  previous  section  have  been  re-organised,  prioritised 
and  in  some  cases  augmented  with  points  arising  from  some  of  the  issues  raised  in  the 
Discussion.  The  recommendations  are  organised  into  three  broad  categories  directed  towards 
defence  research  establishments  (sonar  system  and  human  factors  specialists),  system  developers 
and  the  Navy.  Within  the  section  of  recommendations  to  defence  scientists,  three  broad 
categories  of  priorities  are  suggested.  Within  the  other  sections,  items  are  listed  in  an 
approximate  order  of  descending  priority. 

It  should  be  recognised  that  one  danger  in  organising  the  material  in  this  manner  is  that  the 
different  groups  will  only  heed  the  issues  that  are  addressed  in  their  own  sections.  As  has  been 
stressed  earlier  in  the  discussion,  the  successful  resolution  of  many  of  these  matters  is  not  the 
responsibility  of  a  single  community,  but  an  ongoing  partnership  between  all  parties  in  which 
there  is  a  reciprocal  exchange  of  information  and  ongoing  collaboration  in  finding  solutions  to 
complex  problems  that  cut  across  the  different  domains. 

Defence  Research  Establishments 

Priority  1 

Analysis  Requirements 

■  Analyse  the  operator's  tasks  in  configuring  automated  processes  and  comprehending  the 
impact  of  the  configuration  setting  upon  the  expected  data. 

■  Analyse  the  operator's  understanding  of  the  performance  tradeoffs  associated  with  criterion 
settings  for  automated  functions. 

■  Perform  further  task  and  function  analysis  to  determine  the  operational  functions  to  be 
performed  by  the  UW  team  (ASWC,  Supervisor,  Operator)  using  the  tactical  display.  In 
particular  determine  whether  the  UW  RMP  will  be  compiled  by  members  of  the  sonar  team 
using  the  TIAPS  tactical  display,  and  (in  collaboration  with  the  Navy)  who  in  the  team  will 
have  the  responsibility  for  this  task. 

■  Develop  a  task  network  simulation  of  the  TIAPS  functions,  including  other  generic  UW  C2 
functions  as  necessary. 

Evaluate  the  impact  of  different  numbers,  roles  and  responsibilities  of  the  UW  team 
composition  on  information  flow,  workload  and  the  performance  of  critical  tasks. 

Determine  the  optimum  composition  of  the  UW  team  and  functions  assigned  to  each 
team  member 

■  Perform  cognitive  task  analysis: 

Determine  operator  needs  for  comprehending  the  underwater  environment. 

Determine  the  shared  information  needs  among  UW  team  members  and  higher 
command  levels. 
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Research  requirements 

■  Conduct  research  on  the  best  way  to  provide  a  visual  or  data  representation  of  the 
information  that  will  support  the  operator's  mental  model  for  making  effective  decisions 
concerning  the  configuration  and  evaluation  of  automated  functions. 

Direct  Design  Support 

■  Develop  a  taxonomy  of  user  visual  performance  tasks  and  modes  of  data  representation  to 
provide  guidelines  for  appropriate  display  formats  and  configurations. 

Priority  2 

Analysis  Requirements 

■  Analyse  the  operator's  tasks  in  configuring  the  system  with  a  view  to  providing  information 
for  design  concepts  to  optimising  the  consistency  and  accuracy  of  the  process. 

■  Do  link  analysis  and  other  relevant  analyses  to  determine  optimal  workstation  layout 

Research  requirements 

■  Perform  a  literature  review  to  determine  whether  there  is  relevant  research  in  other  domains 
concerning  operator  trust  in,  and  interaction  with,  automated  systems  with  a  view  to 
acquiring  guidance  on  specific  design  solutions  that  address  issues  of  operator  trust  and 
performance. 

■  Review  literature  on  visualisation  techniques  for  representing  the  underwater  environment. 

■  Evaluate  data  formatting  and  presentation  options  for  optimising  visualisation  of  the 
underwater  environment,  including  colour  coding  and  3d  representations. 

■  Conduct  research  on  how  OR  team  members  communicate  and  share  spatial  information,  the 
nature  of  internal  representations  and  mental  models  and  develop  conceptual  models  and 
guidelines. 

Determine  whether  existing  guidelines  are  adequate  for  determining  the  specific 
format  and  structure  of  data  representations  to  facilitate  rapid  spatial  information 
sharing  among  the  OR  teams. 

Empirically  evaluate  effective  means  of  visually  representing  common  information 
based  upon  guidelines  or,  if  required,  new  research  initiatives. 

■  Evaluate  the  optimum  configuration  of  display  functionality  (number  and  arrangement  of 
monitors,  types  of  display  windows,  composition  of  window  elements)  that  supports  effective 
execution  of  individual  team  member  functions. 

■  Evaluate  impact  of  LCD  technology  for  off  axis  and  low  illumination  viewing. 

■  Review  literature  and/or  conduct  research  on  loss  of  situation  awareness  when  operators  must 
perform  multiple  tasks  in  a  multi-display/multi-window  environment. 
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Direct  Design  Support 

■  Analyse  the  outcome  of  the  literature  review  on  operator  interaction  with  automated 
processes  to  provide  feedback  to  system  developers 

Priority  3 

Analysis  issues 

■  Determine  the  degree  to  which  the  potentially  different  representations  for  the  tactical  display 
can  be  accommodated  within  a  single  window  format,  or  whether  multiple  representations  are 
required. 

OMI  Design  Issues 

■  Generally,  work  with  system  developers  to  develop  an  OMI  style  guide  to  cover  the  standard 
areas  plus  the  following  specific  issues. 

-  guidelines  for  the  use  of  colour  and  symbology,  data  formatting,  layer  filtering  for 
the  tactical  display. 

guidelines  for  display  management 

guidelines  for  LCD  technology,  in  particular,  taking  into  account  issues  of  display 
resolution,  colour  coding,  text  and  symbology. 

appropriate  screen  layouts,  formats  and  navigation  for  supporting  TIAPS 
functionality. 

System  Developers 

■  Develop  design  solutions  that  allow  flexibility  in  the  assignment  of  responsibilities  between 
operators  and  automated  systems. 

■  Provide  functionality  that  allows  operator's  to  easily  comprehend  and  evaluate  the  impact  of 
parameter  and  criterion  settings  of  automated  processes  on  the  data  obtained. 

■  Integrate  the  results  of  HF  and  other  operational  analyses  into  functional  system  design. 

■  Develop  functionality  for  visually  evaluating  the  underwater  environment  for  propagation, 
transmission  and  other  forms  of  analysis. 

■  Develop  functionality  that  allows  operators  to  comprehend  the  integration  of  contact  and 
track  data  with  a  visual  representation  of  the  underwater  environment. 

■  Integrate  the  output  of  HF  and  operational  analysis  of  the  role  of  the  tactical  display  into 
design  solutions  that  optimise  the  format  of  the  OMI  for  different  tasks. 

■  Design  the  overall  display  configuration  to  allow  the  operator  to  maintain  the  relevant 
situation  awareness  when  multi-tasking  and  using  different  display  windows. 

■  Develop  interfaces  that  allow  rapid  selection  of  pre-configured  system  models  based  upon 
contextual  requirements. 
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■  Use  the  output  of  link  analysis  to  optimise  the  physical  layout  of  the  dual  workstation 
configuration. 

■  Develop  OMI  style  guide  for  UW  tactical  displays. 

Navy 

■  In  general,  evaluate  the  operational  implications  for  the  future  roles  of  the  UW  team  in  the 
light  of  the  design  decisions  made  concerning  the  core  TIAPS  functionality.  This  will 
include: 


Manning  levels 

Responsibilities  of  the  supervisor  and  operator 
Relationship  to  the  functions  performed  by  the  ASWC 
Revisions  to  operational  procedure  and  possibly  doctrine 
Training  requirements 

■  Review  existing  operational  problems  and  effectiveness  in  the  use  of  automated  functions  to 
support  command  decision  making  in  general  and  sonar  analysis  specifically. 

■  Consider  the  implications  of  the  heightened  role  of  automated  functions  in  TIAPS  for 
operational  procedures  and  training. 

■  Consider  the  placement  of  responsibility  in  the  UW  team  for  the  tasks  of  developing  the  UW 
tactical  picture  and  compiling  the  RMP  in  the  light  of  the  tactical  display  capabilities  of 
TIAPS. 

■  Develop  mission  scenarios  for  assessing  the  impact  of  TIAPS  on  future  operations. 

■  Have  ongoing  involvement  with  system  designers,  developers  and  defence  scientists  with  a 
view  to  optimising  a  cycle  of  design-build-analyse  in  order  to  identify  core  operational  issues. 

*  Develop  a  test  bed  capability  to  assess  the  effectiveness  and  operational  consequences  of 
automated  aids  to  command  decision  making  and  sonar  analysis. 
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Annex  B1 :  CANTASS  Function  Descriptions 

Name  of  Function 

1.1.1b  RECEIVE  AND  PROCESS  INTELLIGENCE  INFORMATION 
Missions  Under  Which  Function  Occurs 
The  Generic  ASW  Mission 
System  Units  Which  Support  Function 

No  specific  CANTASS  systems  are  involved 
Superordinate  Functions 

1 . 1  CONFIGURE  ARRAY  and  1 .3  SEARCH  FOR  THREAT  TONALS 

Sequential  Categorisation  of  Functions 
Discrete,  concurrent 
Estimate  of  Criticality  of  Function 

This  function  plays  a  large  part  in  determining  the  correct  set  up  of  the  array  receiver, 
tracking,  and  signal  processing  parameters  and  affects  the  subsequent  detection  process. 
Subsequently  (as  a  sub-function  of  1.3),  it  is  also  extremely  important  in  focussing  the  search  for 
particular  tonals— given  that  they  have  been  detected  by  other  sensors 


— 

Critical  Variables 

(i) 

own  ship  speed 

— 

(ii) 

own  ship  manoeuvres 

(iii) 

weather  conditions 

Jr- 

(iv) 

oceanographic  conditions 

(v) 

make-up  of  convoy 

(vi) 

speed  of  advance  of  task  group  and  task  group  manoeuvres 

(vii) 

availability  of  Helo/MPA  support 

(viii) 

availability  of  other  surface  sensor  support 

(ix) 

target  speed 

(x) 

target  range 

(xi) 

target  aspect 

(xii) 

intelligence  on  target 

(xiii) 

contact  held  by  other  sensor 
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(xiv)  communications  status 

(xv)  task  group  command  priorities 

(xvi)  number  of  targets 

Required  Quality  of  Output  for  Function 

It  is  important  to  gain  accurate  information  to  allow  optimal  setting  of  the  array  and 
signal  processing  parameters. 

Estimate  of  Probability  of  Failure  to  Complete  a  Function 

Information  may  be  incomplete 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  have  adequate  intelligence  information  would  probably  result  in  a  failure  to  set 
optimal  parameter  values. 

Failure  to  use  intelligence  (in  proportions  commensurate  with  its  reliability)  will  result  in 
inefficient  use  of  all  available  information 

Estimate  of  Time  to  Completion 

Will  vary  according  to  the  information  source.  None  of  the  information  collection  will 
directly  involve  any  member  of  the  on- watch  CANT  ASS  team. 

Sub-functions  Or  Tasks 

TBD 

Sequencing  of  Sub-functions  or  Tasks 

TBD 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  of  Functions 

The  output  of  this  function  will  directly  affect  the  functions  SET  ARRAY  RECEIVER 
PARAMETERS  (1 . 1 .3)  and  SET  SIGNAL  PROCESSING  PARAMETERS  (1.1 .4),  as  well  as 
ADVISE  ON  SCOPE  AND  DEPTH  OF  ARRAY  (1.1.2). 

Successful  completion  of  this  function  has  consequences  for  all  the  functions  that  involve 
human  input  during  the  mission. 
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Name  of  Function 

2.2.  LOCALISE  TARGET 

Missions  Under  Which  Function  Occurs 
The  Generic  ASW  Mission 
System  Units  Which  Support  Function 

HP# 

Superordinate  Functions 

2  CLASSIFICATION  AND  LOCALIZATION 

Sequential  Categorization  of  Functions 
This  function  is  continuous 
Estimate  of  Criticality  of  Function 

Essential  in  order  to  effectively  prosecute  target 
Critical  Variables 
own  ship  speed 
own  ship  manoeuvres 
oceanographic  conditions 
make-up  of  convoy 

speed  of  advance  of  task  group  and  task  group  manoeuvres 

target  speed 

target  range 

target  aspect 

intelligence  on  target 

contact  held  by  other  sensor 

communications  status 

task  group  command  priorities 

number  of  targets 

Required  Quality  of  Output  for  Function 

Must  be  accurate  to  avoid  missing  a  target. 

Estimate  of  Probability  of  Failure  to  Complete  A  Function 
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Consequences  of  Failure  to  Complete  A  Function 

Failure  to  localise  the  target  may  result  in  missed  targets. 

Estimate  of  Time  to  Completion 

Sub-functions  Or  Tasks 

The  sub-functions  for  LOCALISE  TARGET  are: 

2.2.1  RESOLVE  BEARING  AMBIGUITY 

2.2.2  GENERATE  AREA  OF  PROBABILITY  FOR  LOCALISING  TARGET 

2.2.3  UPDATE  TARGET  DETAIL 
Sequencing  of  Sub-functions  or  Tasks 

See  flow  chart  above 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  Of  Functions 

Unless  this  function  is  completed  the  true  bearing  of  a  possible  threat  will  remain 
dangerously  unknown.  In  most  cases,  LOCALISE  TARGET  (2.2)  will  be  completed  before 
PROVIDE  INFORMATION  FOR  TMA  (2.8)  will  be  started— although  depending  on  the 
situation,  the  Ops  Room  may  call  for  TMA  information  on  an  ambiguous  track. 
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Name  of  Function 

3.2  DETECT  TORPEDO  LAUNCH 

Missions  Under  Which  Function  Occurs 
The  Generic  ASW  Mission 
System  Units  Which  Support  Function 

TBD 

Superordinate  Functions 

3.0  SUPPLY  TRANSIENT,  IRREGULAR,  TONAL  INFORMATION  FOR 

MPA/HELO  OPS 

Sequential  Categorization  of  Functions 
This  function  is  discrete 
Estimate  of  Criticality  of  Function 

Critical  to  avoid  torpedo  prosecution 

Once  detected,  the  critical  first  task  is  to  resolve  ambiguity;  this  is  usually  through  a 
best  guess  based  on  intel,  since  the  signal  information  itself  is  not  usually  useful  in 
providing  clues. 

Critical  Variables 

own  ship  speed 
own  ship  manoeuvres 
weather  conditions 
oceanographic  conditions 
make-up  of  convoy 

speed  of  advance  of  task  group  and  task  group  manoeuvres 

availability  of  Helo/MPA  support 

availability  of  other  surface  sensor  support 

target  speed 

target  range 

target  aspect 

intelligence  on  target 

contact  held  by  other  sensor 

communications  status 

number  of  targets 
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Required  Quality  of  Output  for  Function 

High  quality— torpedo  must  be  detected  to  allow  appropriate  short  term  tactical  decisions 

Estimate  of  Probability  of  Failure  to  Complete  A  Function 

the  signature  is  difficult  to  localise  -  it  appears  only  in  broadband 
operators  have  to  rely  on  contextual  information 
information  rates  are  very  high 

few  operators  have  had  opportunity  to  witness  live  signature 
Consequences  of  Failure  to  Complete  A  Function 
Undetected  torpedo 
Estimate  of  Time  to  Completion 

Sub-functions  Or  Tasks 

?1.3, 

Sequencing  of  Sub-functions  or  Tasks 
TBD 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  Of  Functions 

Mi 
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Name  of  Function 

4.0  SUPPORT  SURFACE  PICTURE 
Missions  Under  Which  Function  Occurs 

Generic  ASW  mission  with  silent  radar 
System  Units  Which  Support  Function 
TBD 

Superordinate  Functions 
Sequential  Categorisation  of  Functions 

TBD 

Estimate  of  Criticality  of  Function 

TBD 

Critical  Variables 

own  ship  speed 
own  ship  manoeuvres 
weather  conditions 
oceanographic  conditions 
make-up  of  convoy 

speed  of  advance  of  task  group  and  task  group  manoeuvres 

availability  of  Helo/MPA  support 

availability  of  other  surface  sensor  support 

target  speed 

target  range 

target  aspect 

intelligence  on  target 

contact  held  by  other  sensor 

communications  status 

number  of  targets 

Required  Quality  of  Output  for  Function 

1© 
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Estimate  of  Probability  of  Failure  to  Complete  A  Function 

m> 

Note:  Operators  are  less  well-trained  in  recognition  of  surface  vessels  and  also  the 
database  of  known  signatures  is  less  complete 

Consequences  of  Failure  to  Complete  A  Function 
Inability  to  built  picture  of  surface  group 
Estimate  of  Time  to  Completion 
TBD 

Sub-functions  Or  Tasks 

1.2,  2.1,  2.2,  2.3,  2.4,  2.6 

Sequencing  of  Sub-functions  or  Tasks 

Allocation  of  Function  to  Man,  Software  or  Hardware 

MAN 

Interdependency  Of  Functions 

Thiislfunction  will  be  affedtb|4Q!soineieg|^e5fcy:!CONHOURE  ARRAlf  (1.1). 
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Name  of  Function 

5.0  PREPARE  OCEANOGRAPHIC  BRIEF  FOR  CO 
Missions  Under  Which  Function  Occurs 
The  Generic  ASW  Mission 
System  Units  Which  Support  Function 
None  directly 
Superordinate  Functions 
Sequential  Categorization  of  Functions 

This  function  happens  once  a  day  with  a  24-hour  overview. 

Estimate  of  Criticality  of  Function 

Important  to  keep  CO  informed  of  mission  progress. 

Critical  Variables 

Required  Quality  of  Output  for  Function 

Accuracy  is  important  because  the  brief  will  influence  decisions  on  how  to  proceed  on 
mission. 

Estimate  of  Probability  of  Failure  to  Complete  A  Function 

This  is  a  required  task  under  standard  operating  procedures,  probability  of  failure  is 
virtually  zero. 

Consequences  of  Failure  to  Complete  A  Function 

CO  and  OR  teams  may  not  receive  critical  information 
Estimate  of  Time  to  Completion 

1  hour  to  prepare  and  ‘A  hour  to  present 
Sub-functions  Or  Tasks 
Sequencing  of  Sub-functions  or  Tasks 
Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  Of  Functions 
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Annex  B2  CANTASS  Function  Flow  Diagrams 

Notes: 

1.  New  functions  are  shown  in  magenta,  re-organised  or  modified  YARD  functions  in  cyan. 

2.  Yellow  highlighted  text  in  the  function  descriptions  represent  areas  of  uncertainty. 

3.  The  sub-functions  under  3.2  Detect  Torpedo  Launch  have  not  been  renumbered  from  the 
original  YARD  at  this  stage.  These  were  originally  second  level  functions  and  would 
become  third  level  functions  under  3.2. 
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Annex  Cl :  TIAPS  Function  Descriptions 


Name  of  Function 

1.0  ANALYSE  MISSION 

Superordinate  Functions 

None 

Sequential  Categorisation  of  Functions 
Discrete 

Estimate  of  Criticality  of  Function 

This  function  plays  a  major  role  in  the  correct  configuration  of  all  the  required  equipment  for  a 
specific  mission  or  operational  environment.  If  equipment  is  not  properly  configured,  it  may 
either  not  operate,  or  operate  incorrectly  and  yield  misleading  data. 

Consequences  of  Failure  to  Complete  A  Function 

The  TIAPS  system  cannot  be  properly  operated  until  this  function  is  performed. 

Sub-functions  or  Tasks 

1.1.  Receive  Information 

1.2.  Configure  workstation 

1.3.  Configure  active  sonar 

1.4.  Configure  passive  sonar 

1.5.  Set  up  required  operating  mode  (fully  passive,  mostly  passive-infrequent  pings,  regular 
active  schedule) 

Sequencing  of  Sub-functions  or  Tasks 
See  flow  diagram 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  of  Functions 
Comments 

This  function  represents  a  critical  first  step  in  ensuring  that  the  equipment  and  environment  is 
appropriately  configured  based  upon  information  received  concerning  the  mission  and  the 
environment.  Some  of  the  sub-functions  associated  with  configuring  active  sonar  must  be  achieved 
with  a  high  level  of  accuracy.  Since  many  operational  contexts  will  have  elements  in  common,  it  is 
likely  that  standardised  procedural  formats  and  databases  of  required  system  settings  will  be 
implemented.  Some  HF  issues  centre  on  the  appropriate  way  to  configure  and  present  to  the  operator 
such  standardised  settings  in  a  way  that  will  allow  this  task  to  be  accomplished  with  speed  and 
accuracy. 
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Name  of  Function 

1 . 1  RECEIVE  ENVIRONMENTAL  INFORMATION 

Superordinate  Functions 
1.0  ANALYSE  MISSION 

Sequential  Categorisation  of  Functions 

Discrete,  continuous 

Estimate  of  Criticality  of  Function 

This  function  plays  a  major  role  in  the  correct  configuration  of  all  the  required  equipment  for  a 
specific  mission  or  operational  environment.  If  equipment  is  not  properly  configured,  it  may 
either  not  operate,  or  operate  incorrectly  and  yield  misleading  data. 

Consequences  of  Failure  to  Complete  A  Function 

The  TIAPS  system  cannot  be  properly  operated  until  this  function  is  properly  performed. 
Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 

See  flow  diagram 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  of  Functions 

1.3  Configure  active  sonar 

1.4  Configure  passive  sonar 

1.5  Set  up  required  operating  mode 

Comments 
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Name  of  Function 

1.2  CONFIGURE  WORKSTATION 

Superordinate  Functions 
1.0  ANALYSE  MISSION 

Sequential  Categorisation  of  Functions 

Discrete 

Estimate  of  Criticality  of  Function 

This  function  plays  a  major  role  in  the  correct  configuration  of  all  the  required  equipment  for  a 
specific  mission  or  operational  environment.  This  function  is  necessary  to  ensure  that  the 
workstation  is  appropriately  configured  for  either  the  supervisor  or  operator  (or  other)  position. 

Consequences  of  Failure  to  Complete  A  Function 

The  TIAPS  system  cannot  be  properly  operated  until  this  function  is  properly  performed. 

Sub-functions  or  Tasks 

1.2. 1  Configure  workstation  for  mission  type 

1.2.2  Set  local  preferences 

Sequencing  of  Sub-functions  or  Tasks 
See  flow  diagram 

Allocation  of  Function  to  Man,  Software  or  Hardware 
MAN 

Interdependency  of  Functions 

1.5  Set  up  required  operating  mode 

Comments 

Each  workstation  may  be  configured  to  assume  different  functional  capabilities  depending  upon 
the  task  to  be  done  and  the  personnel  available.  Typically,  the  workstation  will  be  configured  to 
meet  the  needs  of  supervisor  tasks  or  operator  tasks. 
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Name  of  Function 

1 .3  CONFIGURE  ACTIVE  SONAR 

Superordinate  Functions 
1.0  ANALYSE  MISSION 

Sequential  Categorisation  of  Functions 

Discrete 

Estimate  of  Criticality  of  Function 

This  function  plays  a  major  role  in  the  correct  configuration  of  the  Active  Sonar  sub-system  for  a 
specific  mission  or  operational  environment.  If  this  function  is  performed  improperly,  unreliable 
and  faulty  processed  sonar  data  will  be  generated. 

Consequences  of  Failure  to  Complete  A  Function 

The  Active  sonar  sub-system  cannot  be  properly  operated  until  this  function  is  properly 
performed. 

Sub-functions  or  Tasks 

1.3.1  Set  waveform 

1.3.2  Set  wavetrain 

1.3.3  Set  ping  bundle 

1.3.4  Set  false  alarm  rate  for  autodetectors 

Sequencing  of  Sub-functions  or  Tasks 

See  flow  diagram 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

1.5  Set  up  required  operating  mode 

Comments 

It  is  expected  that  this  task  will  be  done  by  selecting  the  appropriate  parameters  from  a  pre¬ 
existing  database.  The  operator's  task  will  be  to  ensure  that  the  selection  criteria  match  the 
received  information  describing  the  mission  parameters. 
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Name  of  Function 

1 .4  CONFIGURE  PASSIVE  SONAR 


Superordinate  Functions 
1.0  ANALYSE  MISSION 

Sequential  Categorisation  of  Functions 

Discrete 

Estimate  of  Criticality  of  Function 

This  function  plays  a  major  role  in  the  correct  configuration  of  the  Passive  Sonar  sub-system  for 
a  specific  mission  or  operational  environment.  If  this  function  is  performed  improperly, 
unreliable  and  faulty  processed  sonar  data  will  be  generated. 

Consequences  of  Failure  to  Complete  A  Function 

The  passive  sonar  sub-system  cannot  be  properly  operated  until  this  function  is  properly 
performed. 

Sub-functions  or  Tasks 

1.4.1  Set  false  alarm  rate  for  autodetectors 

Sequencing  of  Sub-functions  or  Tasks 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

1.5  Set  up  required  operating  mode 

Comments 

All  of  the  sub-functions  associated  with  configuring  passive  sonar  represent  a  level  of  detail  that 
was  beyond  the  model  template  of  the  YARD  analysis  of  CANTASS.  However,  the  one 
particular  sub-function  identified  (nb.  it  is  acknowledged  that  there  are  many  others)  is  seen  as 
being  of  critical  importance  in  a  future  TIAPS  operational  implementation.  This  is  because  the 
volume  of  passive  sonar  generator  generated  will  be  so  large  that  it  would  be  impractical  for  the 
operator  to  analyse  it  using  the  current  approach  in  CANTASS.  The  operator  will  have  to  rely 
more  on  processes  that  are  "set  up  and  autorun"  and  whose  output  will  then  be  monitored. 
Hence,  the  configuration  of  these  automated  processes  to  yield  a  false  alarm  rate  appropriate  for 
the  operational  environment  is  a  critical  task.  HF  engineering  effort  will  be  required  to  ensure 
that  the  task  is  performed  in  a  highly  accurate  manner. 
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Name  of  Function 

1 . 5  CONFIGURE  OPERATING  MODE 

Note:  The  operating  mode  may  be  fully  passive,  mostly  passive-infrequent  pings,  regular  active 
schedule. 

Superordinate  Functions 
1.0  ANALYSE  MISSION 

Sequential  Categorisation  of  Functions 
Discrete 

Estimate  of  Criticality  of  Function 

The  setting  of  the  operational  mode  is  critical  to  the  achievement  of  appropriate  sonar  data  for  the 
mission  context. 

Consequences  of  Failure  to  Complete  A  Function 

Neither  the  active  nor  the  passive  sonar  sub-system  cannot  be  properly  operated  unless  this 
function  is  properly  performed. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 
Comments 

The  specific  mode  of  operation  will  be  determined  at  the  command  level  and  be  dictated  by 
operational  circumstances.  The  supervisor's  responsibility  will  be  to  ensure  that  the  overall  sonar 
system  configuration  meets  command  intent. 
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Name  of  Function 

2.0  CONFIGURE  SYSTEM  MODEL 

Superordinate  Functions 


Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

The  creation  of  the  system  model  is  critical  to  the  obtaining  appropriate  sonar  data  for  the 
mission  context. 

Consequences  of  Failure  to  Complete  A  Function 

Sonar  range  may  be  compromised.  Sonar  data  may  be  unrepresentative  and  lead  to  errors  in 
detection  and/or  localisation  and/or  classification. 

Sub-functions  or  Tasks 

2. 1  Create  and  maintain  environmental  model 

2.2  Create  and  maintain  sonar  model 

2.3  Evaluate  Model 

2.4  Communicate  values  for  sonar  analysis 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  sequentially 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 


Comments 
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Name  of  Function 

2. 1  CREATE  AND  MAINTAIN  ENVIRONMENTAL  MODEL 

Superordinate  Functions 

2.0  CONFIGURE  SYSTEM  MODEL 

Sequential  Categorisation  of  Functions 
Continuous 

Estimate  of  Criticality  of  Function 

The  creation  of  the  environmental  model  is  critical  to  the  obtaining  appropriate  sonar  data  for  the 
mission  context. 

Consequences  of  Failure  to  Complete  A  Function 

Sonar  range  may  be  compromised.  Sonar  data  may  be  unrepresentative  and  lead  to  errors  in 
detection  and/or  localisation  and/or  classification. 

Sub-functions  or  Tasks 

2.1.1  Add  current  information 

2.1.2  Run  and  refine  model  (based  largely  on  operator  experience) 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  are  performed  sequentially 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

The  current  information  to  be  input  includes:  sound  speed  profile,  location,  sea  state. 

The  refinement  of  the  model  is  a  task  that  depends  heavily  on  operator  experience.  Variables 
include:  ambient  noise,  ownship  noise,  transmission  loss,  time  frequency  and  spatial  spreading, 
bottom  loss  and  reverberation. 
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Name  of  Function 

2.2  CREATE  AND  MAINTAIN  SONAR  MODEL 

Superordinate  Functions 

2.0  CONFIGURE  SYSTEM  MODEL 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

The  creation  of  the  sonar  model  is  critical  to  the  obtaining  appropriate  sonar  data  for  the  mission 
context. 

Consequences  of  Failure  to  Complete  A  Function 

The  sonar  system  will  not  be  optimised  in  a  manner  to  provide  detection  of  expected  threats. 

Sub-functions  or  Tasks 

2.2.1  Update  threat  information 

2.2.2  Update  environment  information 

2.2.3  Run  model 

2.2.4  Array  motion 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  sequentially  and  iteratively 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 
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Name  of  Function 

2.3  EVALUATE  MODEL 

Superordinate  Functions 

2.0  CONFIGURE  SYSTEM  MODEL 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 
Consequences  of  Failure  to  Complete  A  Function 

The  sonar  system  will  not  be  optimised  in  a  manner  to  provide  detection  of  expected  threats. 
Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  is  dependent  on  functions  2. 1  and  2.2 

Comments 
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Name  of  Function 

2.4  COMMUNICATE  VALUES  FOR  SONAR  ANALYSIS 

Superordinate  Functions 

2.0  CONFIGURE  SYSTEM  MODEL 

Sequential  Categorisation  of  Functions 

Discrete 

Estimate  of  Criticality  of  Function 

It  is  important  for  proper  operation  of  the  sonar  system  for  the  parameter  values  to  be 
communicated  accurately  and  completely. 

Consequences  of  Failure  to  Complete  A  Function 

The  sonar  system  will  not  be  optimised  in  a  manner  to  provide  detection  of  expected  threats. 
Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  is  dependent  on  functions  2.1,  2.2  and  2.3 

Comments 

The  operator  may  pass  on  the  model  values,  or  if  experience  indicates  that  they  may  be 
inappropriate,  operator  selected  values. 
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Name  of  Function 
3.0  ASSESS  SYSTEM 

Superordinate  Functions 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 


Consequences  of  Failure  to  Complete  A  Function 

Incomplete  and  or  inaccurate  information  may  be  obtained  from  sonar  processing  and  analysis. 

Sub-functions  or  Tasks 

3.1  Assess  environment 

3.2  Assess  Sonar 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  are  performed  iteratively 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  depends  upon  completion  of  2.0  Set  up  system  model 
Comments 
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Name  of  Function 

3.1  ASSESS  ENVIRONMENT 

Superordinate  Functions 

3.0  ASSESS  SYSTEM 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

This  is  a  core  task  in  ensuring  appropriate  configuration  of  sonar  and  interpretation  of  data. 
Consequences  of  Failure  to  Complete  A  Function 

Incomplete  and  or  inaccurate  information  may  be  obtained  from  sonar  processing  and  analysis. 
Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  depends  upon  completion  of  2.0  Set  up  system  model 
Comments 

This  process  involves  measuring  aspects  of  the  environment  based  upon  information  from 
deployable  sensors  or  information  gathered  from  known  sources  whose  interaction  with  the 
system  model  is  already  established. 
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Name  of  Function 
3.2  ASSESS  SONAR 

Superordinate  Functions 

3.0  ASSESS  SYSTEM 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

This  is  a  core  task  in  ensuring  appropriate  configuration  of  sonar  and  interpretation  of  data. 
Consequences  of  Failure  to  Complete  A  Function 

Incomplete  and  or  inaccurate  information  may  be  obtained  from  sonar  processing  and  analysis. 

Sub-functions  or  Tasks 

3.2.1  Analyse  array  motion 

Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  depends  upon  completion  of  2.0  Set  up  system  model 
Comments 
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Name  of  Function 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 
Superordinate  Functions 


Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

This  is  the  core  function  for  achieving  system  objectives 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 

4. 1  Receive  mission  parameters 

4.2  Manage  TP  overlays 

4.3  Select  and  manage  DII/COE  data 

4.4  Manage  contacts 

4.5  Analyse  contact 

4.6  Manage  Tracks 

4.7  Analyse  tactical  picture 

4.8  Refine  configuration  of  automated  processes 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  continuously  and  iteratively 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  depends  upon  completion  of  2.0  Set  up  system  model  and  3.0  Assess  system 
Comments 

This  function  represents  a  major  departure  from  functions  performed  in  CANTASS  or  active 
sonar.  The  tactical  picture  provides  relevant  information  passed  down  from  command  level.  A 
number  of  overlays  are  selectable  within  the  TP,  as  are  appropriate  data  from  DII/COE.  The  TP 
provides  a  high  level  environment  for  managing  tracks  and  contacts.  Information  created  within 
the  TP  at  the  TIAPS  level  may  be  subsequent  made  available  at  the  command  level.  It  is  possible 
that  the  primary  user  of  the  TP  will  be  the  sonar  supervisor  who  will  switch  between  this  view 
and  lower  level  functions  in  order  to  establish  what  elements  of  the  sonar  picture  are  "real"  and 
what  are  false  alarms  or  artefacts  created  by  semi-autonomous  functions  such  as  autotrackers  and 
track  managers. 
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Name  of  Function 

4 . 1  RECEIVE  MISSION  PARAMETERS 
Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

Accurate  mission  parameters  are  required  in  order  to  properly  configure  the  workstation  and 
establish  the  focus  for  tasks  of  detection  and  classification. 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  depends  upon  completion  of  2.0  Set  up  system  model  and  3.0  Assess  system 
Comments 

Information  made  available  concerning  mission  parameters  includes  PIMS,  threats,  counter¬ 
detection  ranges  -active  and  passive. 
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Name  of  Function 

4.2  MANAGE  TP  OVERLAYS 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

While  this  is  not  a  critical  function,  poor  management  of  overlays  could  lead  to  display  clutter 
and/or  display  of  inappropriate  contextual  information  to  support  tasks  of  detection,  classification 
and  tracking. 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 


Comments 

This  task  is  important  to  ensure  that  the  TP  contains  the  appropriate  amount  of  relevant  overlay 
data  and  irrelevant  data  are  not  displayed. 
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Name  of  Function 

4.3  MANAGE  DII/COE  DATA 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous 

Estimate  of  Criticality  of  Function 

While  this  is  not  a  critical  function,  poor  management  of  DII/COE  data  could  lead  to  display 
clutter  and/or  display  of  inappropriate  contextual  information  to  support  tasks  of  detection, 
classification  and  tracking. 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

Comments 
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Name  of  Function 

4.4  MANAGE  CONTACTS 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 
Continuous 

Estimate  of  Criticality  of  Function 

Depending  on  settings  for  auto-detectors  and  trackers,  there  could  be  a  large  number  of  contacts 
on  the  tactical  display.  Failure  to  disambiguate  threat  from  non-threat  and  "noise"  contacts,  and 
to  reduce  display  clutter  from  a  large  number  of  contacts,  will  lead  to  an  inaccurate  TP  with 
consequences  for  subsequent  ability  to  detect  new  contacts  and  manage  tracks. 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 

4.4.1  Reduce  contact  clutter 

4.4.2  Identify  non-threat  contacts 

4.4.3  Identify  unknown  contacts 

4.4.4  Determine  priority 

4.4.5  Associate/  correlate  contact 

Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

Performance  of  this  function  could  be  degraded  in  Littoral  waters  where  there  is  significant 
potential  for  large  numbers  of  contacts  to  be  detected  by  sensors.  This  function  will  represent  a 
new  task  for  sonar  operators  and  there  remains  a  number  of  outstanding  questions  concerning 
how  this  task  will  be  done,  what  tools  will  be  required  to  support  it  and  how  the  task  will  be 
time-shared  with  other  tasks  that  are  performed  in  sub-functions  to  analyse  contact  data. 
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Name  of  Function 

4.4. 1  REDUCE  CONTACT  CLUTTER 

Superordinate  Functions 
4.4  MANAGE  CONTACTS 

Sequential  Categorisation  of  Functions 
Continuous 

Estimate  of  Criticality  of  Function 

Depending  on  settings  for  auto-detectors  and  trackers,  there  could  be  a  large  number  of  contacts 
on  the  tactical  display.  Failure  to  disambiguate  threat  from  non-threat  and  "noise"  contacts,  and 
to  reduce  display  clutter  from  a  large  number  of  contacts,  will  lead  to  an  inaccurate  TP  with 
consequences  for  subsequent  ability  to  detect  new  contacts  and  manage  tracks. 

Consequences  of  Failure  to  Complete  A  Function 

Contacts  will  fail  to  be  detected,  identified,  classified  and  tracked  with  a  subsequent  impact  upon 
the  Common  Operational  Picture  at  the  command  level. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

It  is  possible  that  one  aspect  of  this  function  will  be  to  eliminate  contacts  from  own  force  tonals. 
It  is  not  known  at  this  stage  how  much  of  this  process  may  be  automated. 
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Name  of  Function 

4.4.2.  IDENTIFY  NON-THREAT  CONTACTS 

Superordinate  Functions 
4.4  MANAGE  CONTACTS 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

These  contacts  must  be  quickly  eliminated  from  the  tactical  display  on  the  basis  of  an  initial 
classification.  The  goal  is  to  use  appropriate  contextual  information  to  ensure  that  the  contact  is 
not  confused  with  a  potential  threat. 

Consequences  of  Failure  to  Complete  A  Function 

Too  much  time  could  be  spent  on  classification  of  non-threats  and  possible  threats  could  be 
classified  as  non-threats. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  subordinate  functions  associated  with  contact 
analysis  (identification  and  classification). 

Comments 
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Name  of  Function 

4.4.3.  IDENTIFY  UNKNOWN  CONTACTS 

Superordinate  Functions 
4.4  MANAGE  CONTACTS 

Sequential  Categorisation  of  Functions 

Iterative 

Estimate  of  Criticality  of  Function 

This  is  a  highly  critical  function.  The  rapid  identification  of  threats  from  other  contacts  is  critical 
for  security  of  the  ship  or  task  group. 

Consequences  of  Failure  to  Complete  A  Function 

The  major  consequence  is  failing  to  detect  a  signal  early  enough  and  hence  a  hostile  sub  may 
penetrate  a  TG  or  screen. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  subsequent  functions  associated  with  contact  analysis 
(identification  and  classification). 

Comments 

The  goal  in  TIAPS  is  to  have  semi-autonomous  processes  monitor  the  detection  of  contacts. 
Hence,  the  role  of  the  operator  will  be  to  monitor  the  output  of  these  processes. 
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Name  of  Function 

4.4.4.  DETERMINE  CONTACT  PRIORITY 

Superordinate  Functions 
4.4  MANAGE  CONTACTS 

Sequential  Categorisation  of  Functions 
Iterative 

Estimate  of  Criticality  of  Function 

There  is  a  moderate  level  of  criticality  to  this  function,  since  if  the  operator  fails  to  identify  the 
appropriate  contacts  to  analyse  first,  potential  threat  contacts  will  have  closed  range  upon  the  ship 
or  TG. 

Consequences  of  Failure  to  Complete  A  Function 

The  major  consequence  is  failing  to  assign  the  appropriate  priority  is  that  a  hostile  sub  may 
penetrate  a  TG  or  screen. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  subsequent  functions  associated  with  contact  analysis 
(identification  and  classification). 

Comments 

This  will  be  an  important  task  for  the  operator  in  Littoral  environments  or  where  there  is  a  large 
number  of  acoustic  sources.  Tools  will  need  to  be  provided  to  allow  the  operator  to  declutter  the 
display  and  to  allow  some  rapid  visual  identification  of  potential  highly  salient  contacts. 


Humansystems  Incorporated  Page  Cl -23 

Final  Report  HF  review  of  OMI  for  Sonar/Combat  Systems  under  Development  at  DREA 


P516264.PDF  [Page:  152  of  202] 


Name  of  Function 

4.4.5.  ASSOCIATE/CORRELATE  CONTACT 

Superordinate  Functions 
4.4  MANAGE  CONTACTS 

Sequential  Categorisation  of  Functions 
Iterative 

Estimate  of  Criticality  of  Function 

There  is  a  moderate  level  of  criticality  to  this  function,  since  if  the  operator  fails  to  identify  the 
appropriate  contextual  information  (if  any)  to  associate  with  the  contact  unnecessary  time  may  be 
spent  on  analysis  of  sonar  data  associated  with  the  contact. 

Consequences  of  Failure  to  Complete  A  Function 

The  major  consequence  is  that  time  will  be  wasted  in  analysing  the  contact. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 

See  associated  flow  diagram 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

This  will  be  an  important  task  for  the  operator;  tools  will  need  to  be  provided  to  allow  the 
operator  to  rapidly  associate  contact  data  with  other  tracks  or  data  on  the  tactical  display. 
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Name  of  Function 

4.5  ANALYSE  CONTACT 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

Contacts  must  be  quickly  eliminated  from  the  tactical  display  on  the  basis  of  an  initial 
classification.  The  goal  is  to  use  appropriate  contextual  information  to  ensure  that  the  contact  is 
not  confused  with  a  potential  threat. 

Consequences  of  Failure  to  Complete  A  Function 

Too  much  time  could  be  spent  on  classification  of  non-threats  and  possible  threats  could  be 
classified  as  non-threats. 

Sub-functions  or  Tasks 

4.5.1  Analyse  passive  sonar  data 

4.5.2  Analyse  active  sonar  data 

Sequencing  of  Sub-functions  or  Tasks 

The  sequencing  of  tasks  will  depend  upon  the  sonar  operational  mode  -  active,  passive  or  a  mix 
of  the  two. 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  2.0  Configure  system  model,  3.0  Assess 
system  and  4.1  Receive  mission  parameters. 

Comments 

The  analysis  of  sonar  data  will  be  assisted  by  processes  that  allow  automated  detection  and 
tracking  of  lines  of  interest. 
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Name  of  Function 

4.5.1  ANALYSE  PASSIVE  SONAR  DATA 

Superordinate  Functions 
4.5  ANALYSE  CONTACT 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  operation  is  fundamental  to  passive  sonar  analysis. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  would  result  in  the  inability  to  distinguish  threats  from  non¬ 
threats  and  hence  degrade  the  overall  tactical  picture  to  the  point  where  it  is  unreliable.  Sub¬ 
function  4. 5. 1.1  would  be  greatly  impacted  as  the  system  would  rapidly  become  populated  with 
unanalysed  data. 

Sub-functions  or  Tasks 

4.5. 1.1  Configure  system 

4.5. 1.2  Search  for  contacts 

4 . 5 . 1 . 3  Classify  contact 

4.5. 1.4  Localise  contact 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  concurrently.  The  search  for  contacts  may  occur  in  parallel  with 
the  classification  and  localisation  of  other  contacts. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

All  functions,  with  the  possible  exception  of  4.5.2  Analyse  active  sonar  are  dependent  upon  this 
function. 

Comments 

The  analysis  of  sonar  data  will  be  assisted  by  processes  that  allow  automated  detection  and 
tracking  of  lines  of  interest.  The  tasks  involved  in  the  actual  analysis  process  will  therefore  be 
somewhat  different  from  those  currently  performed  in  CANT  ASS. 
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Name  of  Function 

4.5 . 1 . 1  CONFIGURE  SYSTEM 

Superordinate  Functions 

4.5.1  ANALYSE  PASSIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 
Discrete  -  may  be  repeated. 

Estimate  of  Criticality  of  Function 

This  operation  is  fundamental  to  ensuring  that  automated  processes  and  threat  apertures  are 
optimised  for  the  environment,  expected  threats  and  tactical  situation. . 

Consequences  of  Failure  to  Complete  A  Function 

It  is  expected  that  automatic  detectors  and  trackers  will  assist  the  contact  analysis  function.  As 
such,  these  processes  need  to  be  appropriately  configured  for  the  situation.  Failure  to  perform 
this  correctly  will  result  in  either  missed  targets  or  too  many  false  alarms. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  4.1  Receive  mission  parameters 
Comments 

This  task  is  a  critical  component  of  ensuring  effective  operation  of  automated  processors.  Some 
research  effort  will  be  required  to  further  understand  what  is  involved  in  this  task  and  what  forms 
of  OMI  will  be  required  to  allow  the  function  to  be  performed  with  the  necessary  accuracy  to 
generate  confidence  in  the  data  obtained. 
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Name  of  Function 

4.5. 1.2  SEARCH  FOR  CONTACTS 


Superordinate  Functions 

4.5.1  ANALYSE  PASSIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 
This  function  is  iterative 


Estimate  of  Criticality  of  Function 

This  operation  is  fundamental  first  step  in  the  analysis  of  passive  data. 

Consequences  of  Failure  to  Complete  A  Function 

The  consequences  of  failure  are  that  display  will  start  to  become  cluttered  with  unanalysed  data, 
the  results  of  which  are  an  inaccurate  tactical  picture  and  the  possibility  of  missing  threats  or 
detecting  them  too  late  for  appropriate  action. 


Sub-functions  or  Tasks 


4.5 . 1 .2. 1  Configure  signal  followers 

4 . 5 . 1 . 2 . 2  Check  what  computer  has  merged 

4.5.1 .2.3  Check  what  auto  process  has  missed 

4.5.1 .2.4  Verify  contacts  that  are  autodetected 

4.5 . 1 .2.5  Select  sonar  display  configuration  mode  (eg  bb/demo) 

4.5. 1.2.6  Initiate  signal  followers  for  weaker  signals  not  auto-detected  (note  these  weaker 

sigs  may  not  be  tracked  automatically,  likely  to  be  targets  of  interest) 

4 . 5 . 1 . 2 . 7  Analyse  acoustic  data 

4 . 5 . 1 . 2 . 8  Analyse  non-acoustic  data 


Sequencing  of  Sub-functions  or  Tasks 
TBD 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  4.5. 1.1  Configure  System 
Comments 

The  search  for  contacts  will  be  a  fundamentally  different  process  from  that  currently  performed  in 
CANTASS.  The  large  number  of  lofargram  and  other  displays  precludes  the  current  practice  of  scrolling 
though  the  beams  to  visually  locate  potential  contacts.  Instead,  pre-configured  autodetectors  will  perform 
some  initial  analysis  and  display  their  output  possibly  in  the  first  instance  on  the  tactical  display.  Other 
forms  of  display  may  be  necessary  to  summarise  this  output  in  a  way  that  allows  rapid  comprehension  in 
the  operator  or  permits  the  operator  to  make  decisions  on  which  contacts  need  to  be  investigated  and 
analysed  further.  Research  will  be  needed  to  understand  this  task  better  and  to  inform  OM1  design  to 
support  the  operator's  comprehension  and  decision  making. 
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Name  of  Function 

4.5. 1.3  CLASSIFY  CONTACT 

Superordinate  Functions 

4.5.1  ANALYSE  PASSIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

This  function  is  continuous  over  a  relatively  short  period  of  time  and  concurrent  with  4.5.1 .2 
Search  for  contacts. 

Estimate  of  Criticality  of  Function 

This  function  is  highly  critical  in  order  to  get  an  early  indication  of  the  threat  value  of  the 
contact. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  rapidly  classify  a  target  may  jeopardise  the  time  available  for  localisation,  particularly 
if  the  potential  threat  is  close  to  the  vulnerability  zone  of  the  task  group. 

Sub-functions  or  Tasks 

The  tasks  involved  in  classification  may  be  somewhat  similar  to  those  currently  performed  in 
CANTASS.  New  operator  aids  in  the  form  of  databases  of  threat  profiles,  smart  cursors  and 
other  decision  aids  are  likely  to  transform  the  specific  tasks  involved  classification. 

Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  4.5. 1.2  Search  for  contacts  and  affects  the 
subsequent  function  4.5. 1.4  Localise  target. 

Comments 

Some  OMI  HF  development  effort  will  be  required  to  ensure  that  tools  and  decision  aids  for 
classification  are  optimised  to  the  operator's  needs.  Threat  libraries,  audio  data  and  time  history 
data  will  be  available  to  assist  this  task. 
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Name  of  Function 

4.5. 1.4  LOCALISE  CONTACT 

Superordinate  Functions 

4.5.1  ANALYSE  PASSIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

This  function  is  continuous  over  a  relatively  short  period  of  time  and  concurrent  with  4.5. 1.2 
Search  for  contacts  and  4.5. 1.3  Classify  contact. 

Estimate  of  Criticality  of  Function 

This  function  is  highly  critical  in  order  to  get  an  early  indication  of  the  threat  value  of  the  contact 
and  its  trajectory  with  respect  to  the  task  group. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  localise  a  target  will  jeopardise  the  ability  to  respond  to  a  threat  that  is  close  to  the 
vulnerability  zone  of  the  task  group,  or  may  waste  resources  in  prosecuting  a  threat  that  is 
moving  out  of  the  immediate  area  of  interest. 

Sub-functions  or  Tasks 

4 . 5 . 1 .4 . 1  Manage  TM A  processor 
See  also  notes  under  "Comments." 

Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  4.5. 1.2  Search  for  contacts  and  4.5. 1.3  Classify 
contacts  and  affects  the  subsequent  function  4.6  Manage  Tracks. 

Comments 

While  the  tasks  involved  in  localisaton  may  be  somewhat  similar  to  those  currently  performed  in 
CANTASS,,  in  TIAPS  they  will  differ  both  in  terms  of  who  does  them  and  how  they  are  done.  Currently, 
localisation  is  a  largely  manual  process  conducted  by  OR  team  members  other  than  CANTASS  operators. 
TIAPS  will  provide  a  capability  for  some  tools  adapted  from  the  existing  Passive  Localisation  Assistant 
(PLA)  to  directly  assist  the  localisation  process.  These  tools  will  provide  an  opportunity  for  operators  to 
input  appropriate  contact  parameters  and  to  allow  visual  analysis  of  the  residual  error  in  computed 
contacted  tracks.  This  should  result  in  a  more  rapid  and  accurate  projection  of  target  speed  and  bearing. 
Research  and  development  effort  will  be  required  to  support  the  OMI  for  these  tools.  It  is  further  possible 
that  some  automated  aids  for  localisation  may  be  able  to  provide  information  at  the  tactical  display  level  to 
show  whether  a  contact  is  rapidly  moving  to  or  away  from  the  task  group,  for  example  in  the  way  a  contact 
is  colour  and/or  blink  coded  on  the  screen. 
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Name  of  Function 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Superordinate  Functions 

4.5. 1  ANALYSE  CONTACT 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  operation  complements  the  function  of  passive  sonar  analysis.  In  cases  where  it  is  not 
feasible  to  deploy  the  array,  or  the  environment  or  tactical  context  reduce  the  reliability  and 
meaningfulness  of  passive  data,  then  active  analysis  provides  the  means  for  detecting,  classifying 
and  possibly  localising  a  contact.  The  function  is  critical  to  operations  involving  prosecution  of  a 
target. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  would  result  in  the  inability  to  distinguish  threats  from  non¬ 
threats  and  hence  degrade  the  overall  tactical  picture  to  the  point  where  it  is  unreliable. 

Sub-functions  or  Tasks 

4.5.2. 1  Check  Bathy  Information 

4. 5. 2. 2  Configure  Transmission 

4. 5. 2. 3  Configure  Receiver 

4. 5. 2. 4  Monitor  performance/progress  of  ping  schedule 

4. 5. 2. 5  Search  for  contacts 

4. 5. 2.6  Analyse  data 

4. 5. 2. 7  Classify  contact 

4. 5.2. 8  Localise  contact 

Sequencing  of  Sub-functions  or  Tasks 
See  function  flow  diagram. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

All  functions,  with  the  possible  exception  of  4.5. 1  Analyse  passive  sonar  are  dependent  upon  this 
function. 

Comments 

Until  a  function  analysis  is  performed  of  existing  hull-mounted  and  variable  depth  sonar,  it  is  not 
possible  to  comment  upon  how  the  active  function  of  TIAPS  will  differ  from  existing  procedures. 
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Name  of  Function 

4.5.2. 1  CHECK  BATHY  INFORMATION 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  task  is  important  to  ensure  that  the  parameters  for  the  transmitter  and  receiver  are 
appropriately  configured  as  environmental  conditions  change. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  would  result  in  the  inability  of  the  active  system  to  produce 
reliable  and  meaningful  data. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software,  Hardware 

Interdependency  of  Functions 

All  functions  subsequent  active  sonar  functions  are  dependent  upon  this  function. . 
Comments 
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Name  of  Function 

4.5. 2. 2  CONFIGURE  TRANSMISSION 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  task  is  important  to  ensure  that  the  transmitter  is  optimised  for  the  environment  and  tactical 
situation. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  would  result  in  the  inability  of  the  active  system  to  produce 
reliable  and  meaningful  data. 

Sub-functions  or  Tasks 

4. 5. 2. 2. 1.1  Set  ping  sequence 

4. 5. 2. 2. 1.2  Set  Waveform 

4. 5. 2. 2. 1.3  Set  Sector 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  are  performed  sequentially. 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  1.3  Configure  Active  Sonar,  2.0  Configure  Sonar  model  and  4.5.2. 1 
Check  Bathy  Information.  Subsequent  functions  are  dependent  upon  this  task  being  performed 
accurately. 

Comments 
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Name  of  Function 

4.5. 2. 3  CONFIGURE  RECEIVER 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  task  is  important  to  ensure  that  the  receiver  is  optimised  for  the  environment  and  tactical 
situation. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  would  result  in  the  inability  of  the  active  system  to  produce 
reliable  and  meaningful  data. 

Sub-functions  or  Tasks 

4. 5. 2. 3.1  Configure  CW 

4. 5. 2. 3. 2  Configure  FM 

4. 5. 2. 3. 3  Configure  ER 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  are  perfromed  sequentially. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  1.3  Configure  Active  Sonar,  2.0  Configure  sonar  model  and  4.5.2. 1 
Check  Bathy  Information.  Subsequent  functions  are  dependent  upon  this  task  being  performed 
accurately. 

Comments 
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Name  of  Function 

4. 5. 2. 4  MONITOR  PERFORMANCE  AND  PROGRESS  OF  PING  SCHEDULE 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent,  iterative. 

Estimate  of  Criticality  of  Function 

This  task  is  important  to  ensure  that  the  schedule  is  followed  as  planned. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  could  result  in  the  loss  of  timely  information  concerning 
contacts  of  interest. 

Sub-functions  or  Tasks 

4. 5. 2.4. 1  Adjust  or  change  model  as  required 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  iteratively. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  1.3  Configure  Active  Sonar,  2.0  Configure  sonar  model  and  4.5.2. 1 
Check  Bathy  Information.  Subsequent  functions  are  dependent  upon  this  task  being  performed 
accurately. 

Comments 
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Name  of  Function 

4.5.2  5  SEARCH  FOR  CONTACTS 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent,  iterative. 

Estimate  of  Criticality  of  Function 

This  task  is  fundamental  to  the  task  of  contact  detection. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  could  result  in  the  loss  of  timely  information  concerning 
contacts  of  interest. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  1.3  Configure  Active  Sonar,  2.0  Configure  Sonar  model  and  4.5.2. 1 
Check  Bathy  Information,  4. 5. 2.2  Configure  Transmission  and  4. 5. 2. 3  Configure  Receiver. 
Subsequent  functions  are  highly  dependent  upon  this  task  being  performed  accurately. 

Comments 

Insufficient  information  is  available  at  present  to  determine  how  this  function  will  be  performed 
in  TIAPS. 
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Name  of  Function 
4.5.2  6  ANALYSE  DATA 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent,  iterative. 

Estimate  of  Criticality  of  Function 

This  task  is  fundamental  to  the  task  of  determining  threats  from  non-threats  as  well  as  for 
localising  and  classifying  the  contact. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  complete  this  function  could  result  in  the  loss  of  timely  information  concerning 
contacts  of  interest. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  1.3  Configure  Active  Sonar,  2.0  Configure  Sonar  Model  and  4.5.2. 1 
Check  Bathy  Information,  4. 5. 2. 2  Configure  Transmission  and  4. 5. 2. 3  Configure  Receiver. 
Subsequent  functions  are  highly  dependent  upon  this  task  being  performed  accurately. 

Comments 

Insufficient  information  is  available  at  present  to  determine  how  this  function  will  be  performed 
in  TIAPS. 
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Name  of  Function 

4.5. 2. 7  CLASSIFY  CONTACT 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent,  iterative. 

Estimate  of  Criticality  of  Function 

This  function  is  highly  critical  in  order  to  get  an  early  indication  of  the  threat  value  of  the 
contact. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  rapidly  classify  a  target  may  jeopardise  the  time  available  for  localisation,  particularly 
if  the  potential  threat  is  close  to  the  vulnerability  zone  of  the  task  group. 

Sub-functions  or  Tasks 

4 . 5 . 2 . 7 . 1  Extract  features 

4. 5. 2. 7.2  Reduce  clutter 

4. 5. 2. 7. 3  Analyse  non-acoustic  data 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  iteratively 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  4. 5. 2. 6  Analyse  Contact  being  performed  accurately. 

Comments 

Insufficient  information  is  available  at  present  to  determine  how  this  function  will  be  performed 
in  TIAPS. 
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Name  of  Function 

4. 5.2. 8  LOCALISE  CONTACT 

Superordinate  Functions 

4.5.2  ANALYSE  ACTIVE  SONAR  DATA 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent,  iterative. 

Estimate  of  Criticality  of  Function 

This  function  is  highly  critical  in  order  to  get  an  early  indication  of  the  threat  value  of  the 
contact. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  localise  a  target  will  jeopardise  the  ability  to  respond  to  a  threat  that  is  close  to  the 
vulnerability  zone  of  the  task  group,  or  may  waste  resources  in  prosecuting  a  threat  that  is 
moving  out  of  the  immediate  area  of  interest. 

Sub-functions  or  Tasks 

4. 5. 2. 8.1  Determine  latitude  and  longitude 

4. 5. 2. 8. 2  Determine  course  and  speed 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  are  performed  iteratively  and  concurrently 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software,  Hardware 

Interdependency  of  Functions 

This  function  relies  on  4. 5. 2. 6  Analyse  Contact  being  performed  accurately. 

Comments 

Insufficient  information  is  available  at  present  to  determine  how  this  function  will  be  performed 
in  TIAPS. 
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Name  of  Function 

4.6  MANAGE  TRACKS 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  the  tactical  picture  is  accurate  and  uncluttered. 
Consequences  of  Failure  to  Complete  A  Function 

The  tactical  display  could  become  rapidly  overpopulated  with  tracks  whose  presence  muddies  the 
tactical  picture.  If  different  tracks  based  upon  the  same  source  are  not  reconciled  then  a  highly 
misleading  tactical  picture  results. 

Sub-functions  or  Tasks 

4.6.1  Maintain  track  positions 

4.6.2  Correlation/associate  tracks 

4.6.3  Maintain  track  database 

4.6.4  Report  tracks 

Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  may  be  performed  concurrently. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  4.4.  Manage  Contacts  and  4.5  Analyse 
Contacts 

Comments 

This  represents  a  potentially  new  task  within  the  sonar  processing  team.  The  tactical  picture  is  a 
core  operational  concept  that  is  shared  among  the  sonar  analysis  team  and  command  levels. 
Managing  this  picture  at  the  sonar  level  will  be  a  critical  and  challenging  task,  in  order  to  ensure 
that  command  has  available  a  current  and  accurate  picture  of  contacts  detected  and  identified  by 
the  sonar  system. 
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Name  of  Function 

4.6. 1  MAINTAIN  TRACK  POSITIONS 

Superordinate  Functions 
4.6  MANAGE  TRACKS 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  the  location  of  tracks  is  accurate. 

Consequences  of  Failure  to  Complete  A  Function 

If  the  track  location  is  incorrect  then  (1)  a  potential  threat  may  intrude  into  the  task  group 
vulnerability  zone,  alternately  (2)  resources  may  be  misallocated  in  pursuing  a  track  which  is  no 
longer  in  a  threatening  location. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

Track  locations  may  be  posted  on  the  tactical  display  either  from  semi-automated  processes,  such 
as  TMA,  or  by  operator  input.  The  supervisor  who  is  managing  the  tracks  will  need  to  know  the 
source  of  the  information  on  which  track  location  is  based,  as  well  as  being  able  to  access  a 
visual  representation  of  the  possible  error  in  location. 
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Name  of  Function 

4.6.2  CORRELATE/ ASSOCIATE  TRACKS 

Superordinate  Functions 
4.6  MANAGE  TRACKS 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  the  identity  and  location  of  tracks  is  accurate.  The 
task  requires  the  supervisor  to  ensure  that  each  track  is  unique  and  not  a  duplicate  and  conversely 
to  ensure  that  tracks  that  have  been  merged  are  not  separate  contacts.  This  function  may  also  be 
of  involved  in  the  process  of  associating  tracks  with  sonar  data. 

Consequences  of  Failure  to  Complete  A  Function 

If  two  tracks  from  the  same  contact  are  not  resolved  rapidly,  unnecessary  time  and  resources  may 
be  spent  in  dealing  with  each  track.  Also  a  failure  to  associate  or  correlate  tracks  may  result  in 
extra  effort  expended  in  identification  and  classification  functions. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

Thus  function  is  dependent  upon  4.4.5  Contact  Correlation/Associate,  4. 5. 1.3  (and  4. 5. 2. 7) 
Classify  contact  and  4. 5. 1.4  (and  4. 5. 2. 8)  Localise  contact. 

Comments 

Research  and  design  effort  will  be  need  to  create  an  appropriate  tool  suite  to  aid  this  process. 
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Name  of  Function 

4.6.3  MAINTAIN  TRACK  DATABASE 

Superordinate  Functions 
4.6  MANAGE  TRACKS 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  less  critical  in  the  short  term,  since  tracks  that  are  the  focus  of  attention  will  be 
displayed  on  the  tactical  picture.  It  is  expected  that  much  of  the  housekeeping  associated  with 
mainataining  the  database  will  be  performed  by  software.  At  present  this  function  tends  to  be  put 
aside  and  delayed  under  conditions  of  heavy  workload. 

Consequences  of  Failure  to  Complete  A  Function 

Failure  to  update  the  track  database  could  result  in  loss  of  time  in  identifying  and/or  processing 
tracks  and  misleading  information  available  at  the  command  level. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Software  (monitored  by  man). 

Interdependency  of  Functions 


Comments 

Maintenance  of  the  track  database  is  a  time  consuming,  paper  and  pencil  and  data  entry  process 
in  current  operations.  Successful  implementation  of  track  maintenance  software  will  result  in  a 
significant  saving  of  operator  resources.  Design  effort  will  be  required  to  provide  the  operator 
with  the  appropriate  tools  to  monitor  the  status  of  the  database  and  to  access  or  modify  its 
contents. 
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Name  of  Function 
4.6.4  REPORT  TRACKS 

Superordinate  Functions 
4.6  MANAGE  TRACKS 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

The  accurate  reporting  of  track  information  is  critical  to  ensuring  that  the  UW  tactical  picture  at 
the  command  level  is  complete  and  accurate. 

Consequences  of  Failure  to  Complete  A  Function 

If  this  function  is  not  completed,  there  would  be  no  UW  tactical  picture  available  at  the  command 
level  with  consequent  serious  consequences  in  the  presence  of  threats. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Software. 

Interdependency  of  Functions 

Depends  on  4.6.1.  Maintain  track  positions,  4.6.2  Correlate/ Associate  tracks  and  4.6.3  Maintain 
track  database. 

Comments 

This  is  expected  to  be  an  automated  process  under  TIAPS.  Command  level  will  be  able  to 
selectively  access  the  required  track  information  maintained  in  the  tactical  picture  or  track 
database. 
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Name  of  Function 

4.7  ANALYSE  TACTICAL  PICTURE 

Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  the  implications  of  the  information  in  the  tactical 
picture  are  interpreted  in  a  tactical  context. 

Consequences  of  Failure  to  Complete  A  Function 

The  tactical  significance  of  UW  information  is  critical  for  accurate  command  decision  making. 

Sub-functions  or  Tasks 

4.7.1  Determine  contact  threat  level 

4.7.2  Ensure  all  tracks  accounted  for 

4.7.3  Delete  contacts  as  required 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  may  be  performed  concurrently. 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  4.4.  Manage  Contacts  and  4.5  Analyse 
Contacts 


Comments 

This  represents  a  potentially  new  task  within  the  sonar  processing  team.  The  tactical  picture  is  a 
core  operational  concept  that  is  shared  among  the  sonar  analysis  team  and  command  levels. 
Analysis  of  this  picture  at  the  sonar  level  will  be  a  critical  and  challenging  task,  in  order  to 
ensure  that  command  has  available  a  current  and  accurate  picture  of  contacts  detected  and 
identified  by  the  sonar  system.  At  present,  it  is  not  possible  to  determine  whether  this  function 
will  be  performed  at  the  sonar  team  level  or  above. 
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Name  of  Function 

4.7.1  DETERMINE  CONTACT  THREAT  LEVEL 

Superordinate  Functions 
4 . 7  ANALYSE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  contacts  are  analysed  in  a  serial  manner  according  to 
their  threat  priority. 

Consequences  of  Failure  to  Complete  A  Function 

Time  would  be  wasted  in  analysing  low  priority  contacts  with  the  consequence  of  leaving 
insufficient  time  to  analyse  and  react  to  threat  contacts. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  4.4.  Manage  Contacts  and  4.5  Analyse 
Contacts 

Comments 

The  goal  in  TIAPS  is  to  provide  visual  coding  cues  to  contact  threat  priority  on  the  tactical 
display. 
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Name  of  Function 

4.7.2  ENSURE  ALL  TRACKS  ACCOUNTED  FOR 

Superordinate  Functions 

4.7  ANALYSE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  no  contacts  are  overlooked  and  have  been 
appropriately  analysed. 

Consequences  of  Failure  to  Complete  A  Function 

A  failure  to  observe  and  analyse  a  track  could  result  in  a  hostile  threat  approaching  the  TG  or 
screen  to  a  point  where  the  appropriate  response  could  not  be  implemented  in  time. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  4.4.  Manage  Contacts  and  4.5  Analyse 
Contacts 

Comments 
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Name  of  Function 

4.7.3  DELETE  CONTACTS  AS  REQUIRED 

Superordinate  Functions 

4.7  ANALYSE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

While  less  critical  than  other  functions,  failure  to  perform  it  will  degrade  the  performance  of 
functions  such  as  4.5. 1.2  Search  for  Contacts. 

Consequences  of  Failure  to  Complete  A  Function 

The  display  could  become  cluttered  with  unreliable  or  tactically  irrelevant  tracks 
Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  4.4.  Manage  Contacts  and  4.5  Analyse 
Contacts 

Comments 

The  goal  in  TIAPS  is  to  provide  visual  coding  cues  to  contact  threat  priority  on  the  tactical 
display. 


Page  Cl -48  Humansysteww  Incorporated 

Final  Report  HF  review  of  OMI  for  Sonar/Combat  Systems  under  Development  at  DREA 


j>51 6264.PDF  [Page:  177  of  202] 


Name  of  Function 

4.8  REFINE  CONFIGURATION  OF  AUTOMATED  PROECESSES 
Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 

Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  automated  processes  provide  accurate  and  reliable 
information. 

Consequences  of  Failure  to  Complete  A  Function 

The  failure  to  perform  this  task  could  mean  that  time  would  be  wasted  in  analysing  auto-detected 
contacts  that  were  due  to  noise  sources,  or,  more  importantly  threat  contacts  may  fail  to  be 
detected. 

Sub-functions  or  Tasks 

4.8.1  Evaluate  Performance  of  Automated  Processes 

4.8.2  Adjust  parameters  of  Automated  Processes 

Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  may  be  performed  concurrently. 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 

This  function  will  be  highly  dependent  upon  functions  3.0  Assess  system  and  4.5  Analyse 
Contact 

Comments 

Failure  to  recognise  that  an  automated  process  is  providing  inaccurate  or  incomplete  information 
represents  a  problem  for  tactical  picture  compilation.  This  task  will  demand  operator  attention 
and  workload  when  operations  are  conducted  in  littoral  environments. 
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Name  of  Function 

4.8.1  EVALUATE  PERFORMANCE  OF  AUTOMATED  PROECESSES 
Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  automated  processes  provide  accurate  and  reliable 
information. 

Consequences  of  Failure  to  Complete  A  Function 

The  failure  to  perform  this  task  could  mean  that  time  would  be  wasted  in  analysing  auto-detected 
contacts  that  were  due  to  noise  sources,  or,  more  importantly  threat  contacts  may  fail  to  be 
detected. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 
Sub  functions  may  be  performed  concurrently. 

Allocation  of  Function  to  Man,  Software  or  Hardware 

Man,  Software 

Interdependency  of  Functions 


Comments 

In  order  for  this  to  be  a  manageable  task  from  a  time  and  workload  perspective,  tools  will  need 
to  be  provided  to  allow  operators  to  assess  readily  the  performance  of  the  automated  process. 
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Name  of  Function 

4.8.2  ADJUST  PARAMETERS  OF  AUTOMATED  PROECESSES 
Superordinate  Functions 

4.0  CREATE  AND  MANAGE  TACTICAL  PICTURE 

Sequential  Categorisation  of  Functions 
Continuous,  concurrent 

Estimate  of  Criticality  of  Function 

This  function  is  important  in  ensuring  that  automated  processes  provide  accurate  and  reliable 
information. 

Consequences  of  Failure  to  Complete  A  Function 

The  failure  to  perform  this  task  could  mean  that  time  would  be  wasted  in  analysing  auto-detected 
contacts  that  were  due  to  noise  sources,  or,  more  importantly  threat  contacts  may  fail  to  be 
detected. 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 

Sub  functions  may  be  performed  concurrently. 

Allocation  of  Function  to  Man,  Software  or  Hardware 
Man,  Software 

Interdependency  of  Functions 


Comments 

Tools  will  need  to  be  provided  to  allow  operators  to  assess  readily  the  consequences  of  adjusting 
parameters  upon  the  performance  of  the  automated  process. 
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Name  of  Function 

5.0  RECORD  AND  ANALYSE  DATA 

Superordinate  Functions 

None 

Sequential  Categorisation  of  Functions 
Continuous,  Concurrent 

Estimate  of  Criticality  of  Function 
TBD 

Consequences  of  Failure  to  Complete  A  Function 
TBD 

Sub-functions  or  Tasks 


Sequencing  of  Sub-functions  or  Tasks 


Allocation  of  Function  to  Man,  Software  or  Hardware 

MAN/Software 

Interdependency  of  Functions 


Comments 

This  function  represents  a  capability  in  the  TIAPS  system  to  record,  report,  playback  and  plot 
specified  time  ordered  data  from  tape.  Since  the  data  plotter  will  have  the  capability  of 
generating  2D  and  3D  graphical  plots  of  numerical  data,  some  HF  research  and  development  may 
be  required  to  optimise  the  OMI.  Further,  some  consideration  should  be  given  to  developing  test 
and  evaluation  requirements  for  data  recording  so  that  selected  data  attributes  and  operator 
actions  and  responses  may  be  recorded  in  a  format  that  will  allow  the  creation  of  some  basic 
measures  of  performance  (MOPs). 


Page  Cl -52  Humaroystems  Incorporated 

Final  Report  HF  review  of  OMI  for  Sonar/Combat  Systems  under  Development  at  DREA 


P516264.PDF  [Page:  181  of  202] 


ANNEX  C2: 

TIAPS 

FUNCTION  FLOW  DIAGRAMS 


P516264.PDF  [Page:  182  of  202] 


Annex  C2:  TIAPS  Function  Flow  Diagrams 
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